I have an E92 M3 with a Solo DL and Smartycam. I tied the AIM CAN bus to my Racecapture and loaded your Smartycam script and it worked great. I now want to add the Shiftx lights. I took the Shiftx script and created a function in the Smartycam script. I then added the new function to the Smartycam onTick loop. The problem is that it looks like the processCAN function never terminates so the Shiftx script never executes. I am also concerned that I am not handling the RPM channel correctly. I would appreciate some help with this. I have also attached a picture of the Shiftx light mount I made for my dash and a picture of my Racecapture installation, Thanks

Hi m3drvr, awesome setup! Looking at your script, the onLites function tries to reference a variable named 'RPM', but from what I can see, it doesn't exist.

For your onLites function, I would use the getChannel() function (https://wiki.autosportlabs.com/RaceCapturePro_Lua_Scripting#getChannel.28_.3CChannel_ID_.7C_Channel_Name.3E_.29), which allows you to read any channel value.

In order to debug this script, I would add some println calls to figure out if your script is working properly. It looks like it should be calling onLites(), how are you determining that the processCan() function never terminates?

_________________Ryan Doherty
Autosports Labs

Tue Aug 02, 2016 3:18 pm

m3drvr

Joined: 31 Jul 2016
Posts: 6

Ryan, thanks for the response. Before I sent the original post, I used println to determine that the script never exited the processCAN function. Based on your recommendation, I added the println commands below to track the state of the ID variable.

function processCAN(chan)
repeat
local id, e, data = rxCAN(chan)
if id ~= nil then
local map = CAN_map[id]
if map ~= nil then
map(data)
end
println(id)
end
until id == nil
println("CAN")
end

I have been looking through the forum for another post about this. Since the script works well at providing data to the dash, perhaps no one else has attempted to use it to process data for other uses. I did find one post where someone was trying to use the CAN data to obtain wheel speeds. https://forum.autosportlabs.com/viewtopic.php?p=23925 but it was never resolved.

Please take a look at this and let me know what you think. I don't fully understand how the CAN mapping works so I am out of ideas. Thanks

Sun Aug 07, 2016 10:13 pm

rdoherty

Joined: 08 Mar 2013
Posts: 215

Hi m3drvr, your script looks correct to me. I chatted with our firmware engineers, what is most likely happening is the Lua script can't read messages from the CAN bus fast enough, so the id variable never is set to null (which happens when there are no more CAN messages to read).

What you can do is create a counter in the processCAN function that is incremented after each message, and have the function exit after a set number of messages. Something like this (untested):

It worked great! The lights are a little sluggish and erratic. I went through the script and removed all of the extra functions and two of the CAN map lines. That improved the performance. Next, I plan to cut the script down to only monitor or log the specific data I need. I'm looking forward to seeing how this works at the track. Thanks for your help.

Tue Aug 09, 2016 3:36 am

rdoherty

Joined: 08 Mar 2013
Posts: 215

Great! If it's sluggish, that may be because the processCAN function is exiting early because it is set to exit after 10 messages. You could try increasing it to 20, or you could increase the tickRate to 50 which may help.

_________________Ryan Doherty
Autosports Labs

Tue Aug 09, 2016 4:51 pm

MikeD

Joined: 29 May 2016
Posts: 39
Location: Austria

Hey guys,

I had the same problem with the script never exiting the processCAN function ... my workaround was a similar solution to yours but instead of using a simple counter I used the getUptime() function (which returns milliseconds from start of the unit IIRC).

With this solution I managed to exit the processCAN function at least after a max dedicated time intervall (in my example down below after a maximum of 40ms) and therefore hoped to not loose much of the CAN messages which is otherwise the case if you interrupt after just a few messages... on the other hand I still have the confidence to get back to the onTick function after the max time that I need for any other functions happening in the onTick loop.

I fed different sinus and other waveform CAN signals into the RCP and observed the datalogs over and over ... this took me lot's of hours trying different scripts until I could get nice and clean, non-interupted waveforms out of the datalogger, which was the final confirmation that I did not lost any sensible amount of CAN packets.

The script example down below is just MY way of reading a dedicated CAN stream that I wanted to receive from a system (wheelspeeds and such at 100Hz broadcast rate), but others may need to use different rates, the simple counter workaround described on a former post from Ryan, a combination of timer and counter or any other approach in case loosing CAN packets is a no-go.

I hope there will be a hardcoded CAN solution in the future for handling CAN messages in a way so that NOTHING gets lost even under high bus load conditions.

Cheers, Mike

EDIT: script example edited

function processCAN(chan)
local maxtime = getUptime() + 40 --max time in ms for loop interupt
repeat
local id, e, data = rxCAN(chan)
if id ~= nil then
local map = CAN_map[id]
if map ~= nil then
map(data)
end
end
until (id == nil) or (maxtime < getUptime())
end

Tue Aug 09, 2016 10:12 pm

rdoherty

Joined: 08 Mar 2013
Posts: 215

Thanks Mike! I'm curious, what tickRate are you setting?

We are thinking about a method of custom CAN configuration that would allow for never losing CAN data, it would involve specifying the CAN ids and conversion formulas via the app. Then RCP can watch the CAN stream for you and log the values.

_________________Ryan Doherty
Autosports Labs

Thu Aug 11, 2016 5:11 pm

MikeD

Joined: 29 May 2016
Posts: 39
Location: Austria

Ryan,

I don't remeber for sure the various script versions that I wrote.
It was one or two months ago when I did these scripting tests and 100+ datalogs to make high traffic CAN reception work for me... tried 30, 50, 100, 200 500, 1000 tick rate... but don't remember which tick rates I used with the counter interupt and which ones with just the regular CAN script, I only remember that it took me endless hours until I was confident to receive the data I was looking for

During my tests I also used the regular countdown way of doing the loop interupt (the script as you desribed above) and it was working fine with a message counter of 40-60 IIRC, so to add to my post from above the easier way for sure is the way you, Ryan, described above.
However I thought to post the timed variant of the script too for those who prefer this kind of doing it.

It may depend a lot on what you want to achieve: Receive as much as possible CAN data or have something very critical happening in the OnTick() function.
In my case I wanted to receive and log lots of CAN data as good as possible and only swap over to the regular OnTick function from time to time to start/stop logging and convert some parameters (GPS Speed from MPH to KPH for example). I'm sure there are various ways of doing what you want with the script... and the best would be the one you hopefully will have up and running in the future where you only have to specify CAN ID's, byte/bit position, factors, offsets and do the rest in the background by firmware...

-Mike

Thu Aug 11, 2016 10:34 pm

m3drvr

Joined: 31 Jul 2016
Posts: 6

Mike,

I finally had a chance to try your getUptime idea. It works perfectly. The shift lights turn on and off without delay. I am now willing to trust them on the track.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou cannot download files in this forum