CAN overload?

[lpettipa]

Hello, see attached script. I'm reading CAN data off bus 0 and 1, and transmitting on bus 1 as well. Bus 1 works fine, bus 0 not so much. I'm using the filters to only allow 3 CAN ID's thru on bus 0, 0x350, 0x359 and 0x340. Here are the rates these ID's are transmitted from the sources:

0x350 - 50hz - logger 1
0x359 - 50hz - logger 1
0x340 - 200hz - ECU 1

When I remove the 0x340 filter, the 0x350 and 0x359 ID transmit and log very nicely. When I add in the 0x340 ID, the 0x340 data looks great, but the other 2 slow down, and randomly get seen at around 1 sample every 5 seconds.

Any thoughts on what is going on here?

I tried 1000hz tickrate as well. Was a little better for the slower ID's, but not right.

Code: Select all

setTickRate(100)

Id1 = addChannel("throttle1",100,1) 
Id2 = addChannel("throttle2", 100,1)
Id3 = addChannel("rpm",100,1)
Id4 = addChannel("press1",100,1)
Id5 = addChannel("counter1",100,1)
Id6 = addChannel("counter2",100,1)
Id7 = addChannel("press2",100,1)
Id8 = addChannel("press3",100,1)
Id9 = addChannel("angle1",100,1)

setCANfilter(1,0,0,0x301,0x1FF)
setCANfilter(0,0,0,0x359,0x1FF)
setCANfilter(0,1,0,0x350,0x1FF)
setCANfilter(0,2,0,0x340,0x1FF)

function onTick()

  id, ext, data = rxCAN(1,100)
  if  id==0x301 then
    throttle1=(data[1]*256+data[2])/10
    setChannel(Id1,throttle1) 
    throttle2=(data[3]*256+data[4])/10
    setChannel(Id2,throttle2)
    rpm_can=(data[5]*256+data[6])*6
    setChannel(Id3,rpm_can)
    press1=(data[7]*256+data[8])
    setChannel(Id4,press1)
  end

  id, ext, data = rxCAN(0, 100)
  if  id==0x350 then
    counter1=data[1]
    setChannel(Id5,counter1)
    counter2=data[2]
    setChannel(Id6,counter2) 
  end
  if  id==0x359 then
    press2=data[1]*256+data[2]
    setChannel(Id7,press2) 
    press3=data[3]*256+data[4]
    setChannel(Id8,press3) 
  end
  if id==0x340 then
    angle1=(data[7]*256+data[8])/10
    setChannel(Id9,angle) 
  end
 
  local tmp1 = getChannel(7)--low boost counter
  local tmp2 = getChannel(8)--hi boost counter
  local tmp3 = math.floor((getChannel(9)*100)/256/100)--boost L
  local tmp4 = math.floor((getChannel(9)*100-tmp3*100*256)/100+.5)
  local tmp5 = math.floor((getChannel(10)*100)/256/100)--boost R
  local tmp6 = math.floor((getChannel(10)*100-tmp5*100*256)/100+.5)
  local tmp7,tmp8 = math.floor((getChannel(11)*100)/256/10)--ign
  local tmp8 = math.floor((getChannel(11)*100-tmp7*10*256)/10+.5)
  local msg = {tmp1,tmp2,tmp3,tmp4,tmp5,tmp6,tmp7,tmp8}
  txCAN(1, 0x302, 0, msg)

end

[lpettipa]

Ok, answering my own question.

Seems that if I use the BMW example script format https://wiki.autosportlabs.com/BMW_E46_CAN , everything works great. I believe the trick is in the code below, on the line that says until msg bigger than 100.

Can not test for real for a few weeks, but a simulation test using my CAN sniffer to send packages at the correct rates to the RCP, all seems to work.

Code: Select all

function processCAN(chan)
    local msg = 0
    repeat
        local id, e, data = rxCAN(chan, 0)
        if id ~= nil then
            local map = CAN_map[id]
            if map ~= nil then
                map(data)         
            end
        end
        msg = msg + 1
    until id == nil or msg > 100
end

[rdoherty]

What is most likely happening here is there is too much data being sent over the CAN bus to RCP for it to handle in any 'good' amount of time. That is why there is the limit of 100 messages being processed per tick, so RCP doesn't get bogged down processing thousands of messages.