Help Please - Numerous ShiftX2 Faults

[VPD]

Hello, can't seem to get ShiftX2 to behave correctly after numerous hours fiddling with it. I suspect it comes down to Lua script problems, but I'm not sure since what I'm trying is essentially a copy and paste sample script...nothing fancy.

Background:
-RC/Track Mk2
-1.14.6 Android app
-Use 2 different android devices, same result (side note Samsung S7, Android 8.0 RC app never closes properly, unrelated)
-2.13.5 firmware
-direct CAN mapped on channels 1 & 2 from car, works fine
-ShiftX2 on CAN 2 using RJ45 splitter
-Disco Light Demo script works fine, starts immediately on RC hardware power up (no app) as intended
-Install allows RC & ShiftX2 to power up before CAN buses are alive
-Struggled with this "bug" - still no feedback viewtopic.php?t=6082
-Portion of script works fine, see below

Faults:
-Won't start on RC hardware power up, only starts after opening app and hitting Run, or flashing a new write
-Once started, RPM linear graph, and RHS Alert 0 (Oil Temp) works fine. LHS Alert 1 will not start or update.
--------This is true no matter what channel I pull into Alert 1, and Water temp updates no problem in the Dashboard
--------If I go to CAN mapping and open the CAN channel edit dialog box for Water and then hit the check mark to close out the window (no edits made), then and only then will Alert 1 turn on and receive a single value. Alert 1 value will never update again until I pretend to edit the CAN mapping again.
-ShiftX2 button press only randomly will report in the log, sometimes 0.0 or 1.0, far from consistent

Other Info:
-on Write reports 16Kb memory used, seems high for small script. What is included in that memory value?
-Flashing a new write will often cause the Wifi connection to be killed and reports back "Port Closed," typically takes multiple tries to achieve successful write
-Using the Poll feature often creates hangs and generates various error messages, kills connection, etc.

Code: Select all

--[[RPM Shift, Water & Oil Alerts]]

sxCan=1
sxId=0
tickRate=30
sxBright, sxScale=0,51 --[[0 auto 1-100, 51 default 0-255]]

function sxOnUpdate() --[[updates on tick]]
  sxUpdateLinearGraph(getChannel("RPM"))
  sxUpdateAlert(0,getChannel("OilTemp")) --[[rhs LED]]
  sxUpdateAlert(1,getChannel("Water")) --[[lhs LED]]
end

function sxOnInit()
  --[[L->R, smooth linear, min, max range]]
  sxCfgLinearGraph(0,0,0,7300) 

  sxSetLinearThresh(0,0,2000,0  ,255,0  ,0) --[[green]]
  sxSetLinearThresh(1,0,3500,255,255,0  ,0) --[[yellow]]
  sxSetLinearThresh(2,0,6000,255,0  ,0  ,0) --[[red]]
  sxSetLinearThresh(3,0,6500,255,255,255,10) --[[white flash]]

  --[[config rhs LED, oil temp]]
  sxSetAlertThresh(0,0,0  ,0  ,0  ,255,1) --[[blue flash]]
  sxSetAlertThresh(0,1,180,0  ,255,0  ,0) --[[green]]
  sxSetAlertThresh(0,2,210,255,255,0  ,0) --[[yellow]]
  sxSetAlertThresh(0,3,225,255,0  ,0  ,0) --[[red]]
  sxSetAlertThresh(0,4,240,255,0  ,0  ,10) --[[red flash]]

  --[[config lhs LED, water temp]]
  sxSetAlertThresh(1,0,0  ,0  ,0  ,255,1) --[[blue flash]]
  sxSetAlertThresh(1,1,160,0  ,255,0  ,0) --[[green]]
  sxSetAlertThresh(1,2,200,255,255,0  ,0) --[[yellow]]
  sxSetAlertThresh(1,3,210,255,0  ,0  ,0) --[[red]]
  sxSetAlertThresh(1,4,220,255,0  ,0  ,10) --[[red flash]]
end

function sxOnBut(b) --[[button state change]]
  println('button: ' ..b)
end

--[[ShiftX2 functions]]

function sxSetLed(i,l,r,g,b,f)
  sxTx(10,{i,l,r,g,b,f})
end

function sxSetLinearThresh(id,s,th,r,g,b,f)
  sxTx(41,{id,s,spl(th),sph(th),r,g,b,f})
end

function sxSetAlertThresh(id,tid,th,r,g,b,f)
  sxTx(21,{id,tid,spl(th),sph(th),r,g,b,f})
end

function setBaseConfig(bright,scale)
  sxTx(3,{bright,scale})
end

function sxSetAlert(id,r,g,b,f)
  sxTx(20,{id,r,g,b,f})
end

function sxUpdateAlert(id,v)
  if v~=nil then sxTx(22,{id,spl(v),sph(v)}) end
end

function sxCfgLinearGraph(rs,ls,lr,hr) 
  sxTx(40,{rs,ls,spl(lr),sph(lr),spl(hr),sph(hr)})
end

function sxUpdateLinearGraph(v)
  if v ~= nil then sxTx(42,{spl(v),sph(v)}) end
end

function sxInit()
  println('config shiftX2')
  setBaseConfig(sxBright,sxScale)
  if sxOnInit~=nil then sxOnInit() end
end

function sxChkCan()
  id,ext,data=rxCAN(sxCan,0)
  if id==sxCanId then sxInit() end
  if id==sxCanId+60 and sxOnBut~=nil then sxOnBut(data[1]) end
end

function sxProcess()
  sxChkCan()
  if sxOnUpdate~=nil then sxOnUpdate() end
end

function sxTx(offset, data)
  txCAN(sxCan, sxCanId + offset, 1, data)
  sleep(10)
end

function spl(v) return bit.band(v,0xFF) end
function sph(v) return bit.rshift(bit.band(v,0xFF00),8) end

function onTick()
  sxProcess()
  collectgarbage()
end

sxCanId = 0xE3600 + (256 * sxId)
println('shiftX2 base id '..sxCanId)

setTickRate(tickRate)
sxInit()

[VPD]

This morning I tried another test, I commented out the sxUpdateAlert for ID 0 (oil temp) and made no other changes.

--sxUpdateAlert(0,getChannel("OilTemp")) --[[rhs LED]]

Now ID 1 will run and update continuously whereas before it would do neither. It now seems something about the setup will not allow both Alert ID's to work simultaneously, but the issue is not specific to ID 1 as I previously thought. Either way, it still won't work until I Run the script from within the RC app.

Is anyone else running ShiftX2 from RC/Track Mk2 with both Alert ID's working?

[brentp]

Hi,

Thanks for the note. It looks like you might be running into some memory issues with your current script.

We have some good news; with the new 2.15.0 firmware we built for ShiftX3 support, we have now bundled built-in functions to support ShiftX3 -- which will also work with ShiftX2. This built-in support will reduce the memory footprint of your system.

You can see the current sample scripts for ShiftX3 here - note how small they are compared to the original scripts for ShiftX2.
https://wiki.autosportlabs.com/ShiftX3

We will be updating the sample scripts for ShiftX2 as well to reflect the improvements made in the firmware.

We are working on making these changes to the wiki and documentation and will follow up here when complete.

Also, the latest app improves the lua scripting window to make it easier to navigate and edit in a mobile environment; be sure download and update when you can.

Thanks,

[VPD]

Hi Brent. As posted above I am using the 1.14.6 android app which is the latest version I see in Google Play Store. What app version are you referring to?

As for firmware, I see you just updated the downloads page to show 2.15.0 Track Mk2 now, I was wondering if this might be a firmware problem. I don't see a firmware update process for TC Track, do I follow the RC Pro firmware update process?

What features really eat into the memory Lua needs? Number of CAN channels directly mapped, etc.? Maybe I can reduce usage other ways.

[VPD]

I updated to 2.15.0 firmware and I'm cautiously optimistic... that it mostly works. It still won't start the script on power up. It requires launching the app and hitting Run.

It took multiple flashes and multiple power cycles to get the new ShiftX3 based script (I removed all the gear related code) loaded and working. Strangely it would behave erratically in between each attempt, seemingly mixing portions of old and new script like the flash can't seem to purge the old. Polling the log kept reporting "event overrun" and despite the smaller script still reports 16K memory usage.

It's disconcerting the sample scripts advertised / lack of adequate memory supplied leads to so many problems.

2 Questions
1) What other features really consume the memory Lua needs? Number of CAN channels mapped, etc.? What else can I do to reduce memory?
2) With the new 2.15.0 firmware, is there missing code in the sample X3 script leading to failure to start on power up? How do I initialize it to fix this?

[brentp]

Hi, Can you post your current script that doesn't work? We can show you how to change it given the changes in the 2.15.0 firmware.

For 1) CAN channes do not affect Lua memory availability. 2) There's no missing code in the example, we've bundled many of the ShiftX2/3 support functions natively into the firmware.

While we look at your script, can you try the Demo script here with your ShiftX2? Be sure to first erase any script you might have before copy/pasting the script in.

https://wiki.autosportlabs.com/ShiftX3# ... ights_Demo

Thanks!

[VPD]

Below is my script. Its a direct copy paste from the X3 product page. Only mods are delete gear code and change channel names/values to match mine. I use TPS_Pedal to test RPM shift light behavior. Through all this the linear graph has worked pretty well the whole time, just the alert lights and script start on power up remain goofy.

I always delete the full script before pasting a new one, I've even tried flashing a blank script window in between new scripts - doesn't make a difference.

I downloaded and flashed the X3 disco demo script and it worked just fine, even starts immediately on power up. This is the same result I had with the X2 disco demo too, it worked 100% as intended on the old firmware.

When a non disco demo script is flashed, the X2 light behavior reverts back to its initial behavior as if only power and ground are connected (the linear graph sweeps back and forth and the alerts flash in unison as it steps through the colors), this is true whether the CAN bus is alive or not. Hit Run and that stops and the script starts. Makes me think it doesn't even know the script is there.

Last, I noticed in the poll log tonight during start up it says something like "[OBD] Init Current Values." Is it defaulting to expecting OBD data instead of knowing I am using direct CAN mapping instead on power up? Might that explain some of it? Disco demo is not dependent on data so incorrect source wouldn't matter.

Code: Select all

setTickRate(30)

-- Set ShiftX3 configuration parameters with default parameters
-- orientation: 0=normal, 1=inverted (display above LED bar)
-- brightness: 0-100%, 0 = auto brightness
-- can bus: 0=CAN1, 1=CAN2
sxSetConfig(0,0,1)

--config shift light
sxCfgLinearGraph(0,0,0,100) --left to right graph, smooth style, 0 - 7000 RPM range

sxSetLinearThresh(0,0,30,0,255,0,0) --green
sxSetLinearThresh(1,0,50,255,255,0,0) --yellow
sxSetLinearThresh(2,0,60,255,0,0,0) --red
sxSetLinearThresh(3,0,65,255,255,255,10) --whiteflash


--configure first alert (right LED) as engine temperature (F)
sxSetAlertThresh(1,0,40,255,255,0,0) --yellow warning at 205F
sxSetAlertThresh(1,1,60,255,0,0,10) -- red flash at 225F

--configure second alert (left LED) as oil pressure (PSI)
sxSetAlertThresh(0,0,40,255,0,0,10) --red flash below 15 psi
sxSetAlertThresh(0,1,60,255,255,0,5) --yellow flash 15-20 PSI

function onTick()
  --update RPM
  sxUpdateLinearGraph(getChannel("TPS_Pedal"))
  --update engine temp alert
  sxUpdateAlert(1, getChannel("Water"))
  --update oil pressure alert
  sxUpdateAlert(0, getChannel("OilTemp"))
end

[brentp]

Hi, Thanks for the reply.

When you say "just the alert lights and script start on power up remain goofy" what do you mean exactly by "goofy"?

Are you able to vary the value on the channel associated with the alert to test it's behavior? e.g. you can associate it with the TPS signal just to see what it's doing.

Also, can you describe your wiring? Is this testing on a bench or already installed in the car? how long is the cable and what kind of cable/wiring do you have connecting the two? We should rule out any electrical issues which might interfere with communications.

Also, the OBDII notes in the log do not affect ShiftX2's operation.

[VPD]

I think I've answered the goofy questions above. Yes, once the script is working the linear graph and alert lights are correctly associated and values update. I've played around with it enough to be confident in that now. The new 2.15 firmware fixed this aspect as far as I can tell. This wasn't true on the old firmware, above you can read how the alert lights were temperamental using the old firmware. The multiple flashes and power cycles to get a new script working is still true though. Other users have documented this too on the forum.

I'm using RJ45 Cat cables and splitters per your wiring guide, and it's installed in the car. Cable length is 5' max. I've done all the basic electrical checks and combined with proper functioning lights once you Run the script, t's clear the wiring job is solid.

At this point I believe the focus should be only getting the script to run on power up so I don't have to launch it from the app each time. Fix that and I think we're good assuming your initial low memory diagnosis isn't lurking, I have plans to leverage Lua for more than this.

[brentp]

Thanks for the clarification.

When things are power cycled, are ShiftX2 and RCP powered on simultaneously, or are you powering them on separately, where one has power and the other does not?

Also, try this:

Set the app to poll the log (under the scripting window).

Then, power everything off, and then power everything back on simultaneously. Let the app poll the log upon startup. Do you see a script error?

If you see no script error, does the ShiftX2 ever fire up and start responding to the script, or does it always and forever just show the startup 'scanning'?

Also, so we can keep track of things, can you llink the forum URLs for the other cases ("Other users have documented this too on the forum. ")

Also, also, does the disco light demo exhibit the same problem - it won't startup correctly from a power on, (and you need to hit the 'run' button)?
Thanks,

[VPD]

Everything is powered up simultaneously, the power for RC is shared with X2 by way of the RJ45 splitter.

I'll do the start poll log and power cycle test tomorrow and report back any errors.

With a "real" script loaded the X2 never fires up the script, the startup "scanning" continues for a while and eventually ends. Even after the scanning lights end there is no script response, it's just dead until I hit "Run"

I answered the disco light question above. It starts immediately on power up as intended. "I downloaded and flashed the X3 disco demo script and it worked just fine, even starts immediately on power up. This is the same result I had with the X2 disco demo too, it worked 100% as intended on the old firmware. " Because it does not depend on data but real scripts do, this feels like a clue.

Can you fully replicate my hardware, direct CAN mapping, and script setup and see what you get?

[brentp]

Got it.

Try this - add the following command right before sxSetConfig

sleep(500)

and see if that makes a difference.

[VPD]

As requested I turned polling on and power cycled RC. While monitoring using the windows app over USB the only message returned at power up is:

[ShiftX] Received configuration message for base address: 931328

Then I tried adding the sleep(500) and power cycled again. Same message in the poll and no change in behavior except the "scanning" lights delayed starting, BUT only the first time. I power cycled again and the "scanning" lights never started, but neither did the script. I then changed the sleep timer to 2000 then 5000 and each time I also changed an LED color. The "scanning" lights never started and the script never did either, no matter the timer. After the script didn't run automatically, each I time I would then hit "run" manually and everything in the script worked. By changing an LED color each time, I could confirm the write flash worked each time.

When I hit "Run" manually this is the poll:

[lua] Gracefully stopping Lua Task
[lua] Destroying Lua State
[lua] Initializing Lua state
[lua] memory usage: 16KB
[lua] Starting Lua Task
[lua] Loading script. Length: 1126
[lua] Successfully loaded script.

So now what?

[brentp]

Thanks for the update.

Hm, I think to normalize the test conditions for your environment and ours, I will provide a test script that creates simulated channels within the script, instead of relying on sensor channels. This will provide a baseline for comparison and we can work from there. I should have something available tomorrow morning.

Thanks for working through this!

[brentp]

Hi, Here's a configuration that will exactly replicate what we have testing here.

This script creates 3 simulated channels that cycle up and down automatically.

See if this works reliably when you power cycle everything together.

Worth noting, when you are doing your power cycling test, make sure you're disconnected from USB, since your laptop will otherwise keep RCP powered up.