Odd CAN / scripting behavior with RCP Mk2

[thoraxe]

Background
I have an RCP Mk2

I currently have various channels mapped via CAN mapping. For example, TPS and RPM.

Currently I'm also doing a dumb mirror:

Code: Select all

  -- grab data off CAN0 and retransmit on CAN1 as long as there's data
  id, ext, data = rxCAN(0)
  if (id ~= nil) then
    txCAN(1, id, ext, data)
    if sniffcan == 1
    then
      print('[' ..id ..']: ')
      for i = 1,#data do
        print(data[i] ..', ')
      end
      println('')
    end
  end

I have a Haltech ECU on CAN0 that transmits different channels at different rates (transmit frequency/rate, NOT CAN baud rate) on the bus. For example, some values are 5Hz and some values are 50Hz. I am also trying to attach my Haltech WB02 on the same CAN bus.

On RCP CAN1 I have an AEM dashboard. It is seeing and displaying whatever is transmit by the RCP's various scripts.

Issue
I am having two distinct issues. One is when the Haltech WB02 is connected to the CAN0 bus, and the other when it is not.

With WB02 disconnected
This issue always seems to occur. My AEM dashboard seems to update certain items very slowly.

It seems to take a really long time for certain values to "show up" on the dashboard when I turn it on. As an example, the dashboard, ECU and RCP have been ON for quite some time, but it still has not updated the oil temperature display.

Oddly enough, oil pressure updated almost immediately.

According to Haltech's CAN protocol:

oil pressure is sent at 50Hz.
oil temp is sent at 5Hz.

I currently have my onTick in my script set at 60.

My supposition is that there is some weird issue where trying to read the CAN bus via a Lua script while it is being read by can mapping is resulting in some odd behavior. Or that reading the CAN bus on a specific tick is resulting in not picking up all of the data due to a mismatch in transmit rate (not baud rate).

According to the Haltech CAN protocol, oil temperature is sent on channel 3E0 (decimal 992). Looking at my sniffed/printed messages, I basically never see a message on channel 992 come through. That would explain why the dash never/infrequently updates.

With WB02 CONNECTED
When I connect the Haltech WB02 to the bus, and then look at the sniffed messages, I basically only see the CAN messages from the WBO2. At first I though this was some kind of termination resistance issue. I actually had a Haltech wiring issue (incorrect pinning of their Tyco connector). I resolved the wiring problem, and then the dropped messages problem seemed to go away.

But now it appears to be back. But I am also wondering if this is somehow related to the onTick message reading. I don't currently have an actual CAN sniffer, but I am considering in investing in one. Putting a sniffer port right by the RCP CAN connector would show me really what the RCP is receiving, and would allow me to eliminate any wiring issues.

At least with the WBO2 disconnected I know I am receiving ECU messages. So let's ignore that situation for now and focus only on the sniffed / onTick messages.

The Question
What is going on with the sniffed/printed onTick messages and why are some messages apparently never hitting the RCP? Given that I don't have any other sniffer/scanner at present, I can't prove the messages aren't getting to the RCP, but I'd like for someone to prove why the RCP should be displaying them.

Thanks.

[brentp]

Hi Erik,

You could be having two issues:

* Lua script cannot keep up, due to CAN messages being received too fast - and some messages are getting dropped. You can test this indirectly seeing if your CAN receive loop ever exists. If the script is being saturated by CAN messages, it will never exit the loop and return from the onTick() function.

* Electrical issue on the CAN bus. There could be a wiring or impedance / termination issue. Putting an oscilloscope on the lines under different conditions and at different points would be helpful. If the waveform is nice and square, then you have a good signal.

Hope this helps, let us know what you find out.

[thoraxe]

Hi Erik,

You could be having two issues:

* Lua script cannot keep up, due to CAN messages being received too fast - and some messages are getting dropped. You can test this indirectly seeing if your CAN receive loop ever exists. If the script is being saturated by CAN messages, it will never exit the loop and return from the onTick() function.

* Electrical issue on the CAN bus. There could be a wiring or impedance / termination issue. Putting an oscilloscope on the lines under different conditions and at different points would be helpful. If the waveform is nice and square, then you have a good signal.

Hope this helps, let us know what you find out.

How would I know if I am exiting the loop and returning from onTick?

When I set the tick rate to either 1 or 60 or 100 and look at the log I see pile after pile of messages, so my assumption is that the loop is exiting. I am happy to add anything extra you can think of to the loop to validate that the receive loop is exiting.

How does the Lua CAN receive work differently than the CAN mapping? If you look at viewtopic.php?t=5814

I could probably get "around" the receive quantity problem (if that is the problem) by just transmitting what I wanted from the mapping.

Thoughts?

[brentp]

You can tell if onTick() is exiting by putting a println statement right before the exit of onTick():

println("ontick exiting")