Now I use "CAN" and want to send 8 commands in a program, among which 6 commands have the same frame ID. The following is part of the screenshot of my program. My problem now is that what I read is the result after the execution of the first command, and I want to see the result of the execution of the following commands. If not, do I have to break them down into steps using TestStand?The ID of the third through eighth commands must be 773.My program now has to loop through the first to third commands.Fourth to eighth command, just run it once, so for fourth to eighth command I used a parallel structure.
please help me. Thanky you.😭
Solved! Go to Solution.
The idea of CAN is actually to use different IDs to be able to distinguish messages. If you send out 5 messages to ID 500 and the counterpart would reply using the same ID or a specific ID that is connected to 500, then the replies would also all have the same ID. You couldn't sort of to which of the 5 sent messages which reply belongs. The code you built is also asynchronous.
I would do it differently. The loops are only for sending and receiving, they don't define the ID. The ID and the related payload would be placed in variables outside of these two loops. The outer loop would this way define what to send and when.
It sounds like you have some kind of command and response API. For this you will likely want some of your code to be in series, where you send the command, and then wait for the specific response with some kind of timeout. Part 6 of my CAN blog goes over the multiple different XNet session types, which can help in waiting for various responses.
The idea of CAN is actually to use different IDs to be able to distinguish messages.
CAN allows for "multiplexing" messages. The CAN driver handles such messages by parsing the "multiplexer" value. So one ArbID can be used to transfer a large number of signal values…
I had to implement such messages just two weeks ago and now I know the (old) NI-CAN driver handles multiplexed messages off-the-shelf (when the DBC is well-defined)!
XNet also handles multiplexed signals fairly well. However I found a few behaviors of it to what I would consider a bug. When I developed the Frame Signal conversion I changed the behavior of these conversions to be in line with what I thought they should be.
But still since OP was talking about seeing a response, I suspect they are doing something else like the ISO15765, UDS, KWP2000, or some other command response scheme.
Thank you for your help.Just like you said,we use the UDS protocol.I don't know if DBC and multiplexing mentioned above can be used if we use UDS protocol.Because the above blog link I can't open here.
Thank you for your reply.Which NI-CAN program should I use to process the multiplexing information? With a state machine or producer, consumer structure?
Which NI-CAN program should I use to process the multiplexing information? With a state machine or producer, consumer structure?
What you show in this image is not NI-CAN, you clearly show NI-XNET…
With NI-CAN all you need to do is to supply a proper DBC file to read signals from multiplexed messages. No additional routines (like the mentioned state machine or P-C structure) is needed…
I'm not experienced in using NI-XNET, so you better ask Hooovahh!
@GerdW: I know, that's how we do it in our CAN interface. But we at least have a specific ID for queries and responses. Not sure what he has there.
@xiaosanhe1224: if I may add my two cents to the probably still coming answer of GerdW... The multiplexing can be sorted out using a DBC. I personally never worked with CAN under LabVIEW and cannot say that for sure, but I doubt that any VI, no matter if NI-CAN or NI-XNET, has an extra function for multiplexing.
The idea is just to use one of the 8 bytes in a CAN message as multiplexor, perhaps two. This would usually be the first one or first two.
They define how to handle the rest of the payload, similar to ModBus. Maybe you need to program this yourself, but it's not much. You would index an array.