How are Multiple-Modes of a Multiplexed CAN Message Sent Using XNET?

[William_Griffin]

I need to periodically send multiple modes of a multiplexed CAN message using XNET.

To test this out, I've created the VI shown below. The "CAN_Test_DB" contains one CAN message called "Test_Message". This has one multiplexer caled "CmdByte". There are also two signals defined for this message. The signal "CB76_Signal" corresponds to the multiplexer's mode value of 76. The signal "CB77_Signal" corresponds to the multiplexer's mode value of 77. I should also mention for my testing, I connected CAN1 to CAN2 so that I can read and verify the outputs of CAN1.

Unfortunately, the code as shown in the picture does not work. It appears that only the second "CmdByte" value in the "Signal Out Data" array is actually maintained in the session. If Signal_Out_Data[2] = 76, then only CB76_Signal is sent on the CAN network. If Signal_Out_Data[2] = 77, then only CB77_Signal is sent on the CAN network. Signal_Out_Data[0] is essentially ignored.

I have attached this code and the corresponding database for others to try out. You'll see that I have created a few other diagrams in the "Disable Diagram Structure" while trying out a few other options. When CmdByte is not explicitly included, I get an error (which I think is strange - the signal can only be sent with a specific mode that is defined in the database, so that should be implicitly applied). If I only include CmdByte once, then only the signal with a mode value corrsponding the value of the CmdByte that is explicitly set is sent. Another alternative I tried was to include these signals on seperate XNET sessions, but this also returns an error stating that you can only open a particular frame once.

Does anyone have any suggestions for how this might be resolved? If there is not a solution, then I would suggest that this is a major hole in the XNET solution. The reason multiplexers exist is so that multiple messages can be sent out containing different data in the different modes. If you can't send multiple modes, then we've really lost the benefit of this functionality.

[Tamdemonium]

Hi William -

So looking at some of the documentation for XNET: Getting Started with the NI-XNET API for LabVIEW there is one section that specifically says "NI-XNET enables you to create sessions for multiple hardware interfaces. For each interface, you can use multiple input sessions and multiple output sessions simultaneously. The sessions can use different modes. For example, you can use a Signal Input Single-Point Mode session at the same time you use a Frame Input Stream Mode session."

In regards to the error you receive for multiple sessions: The limitations on sessions relate primarily to a specific frame or its signals. For example, if you create a Frame Output Queued session for frameA, then create a Signal Output Single-Point session for frameA.signalB (a signal in frameA), NI-XNET returns an error. This combination of sessions is not allowed, because writing data for the same frame with

two sessions would result in inconsistent sequences of data on the network.

As to using different modes with NI-XNET, the documentation says it is possible for single signals but I do not think it will be possible with multiple multiplexed signals.

From initial glance at the code: When using the XNET Write (Signal Single-Point) VI, it is important to be aware of the fact that there is no queue to store signal values when transmitting. If you therefore call the XNET Write VI a second time before the next transmission, only the second signal will be transmitted in the frame across the bus. Similarly on the receiving end, the XNET Read (Signal Single-Point) VI does not queue received data and will therefore only read the most recently received value. Therefore, if two frames are received prior to calling the XNET Read.vi, only the second frame of signal data will be returned.

It may be worth first checking the time interval between writing the two signals and also the speed at which they are read. As you can see, transmitting multiple signals this way with no queue poses the issue of lost data if all time intervals are not manually taken into account.

The write VI which you are using allows you to provide a list of signals that you wish to send out. If the signals are specified in multiple frames, the XNET driver will send out multiple frames.  This is part of the abstraction it provides.  When you write the same signal twice within the list provided to the Write VI, the XNET driver sees it as two copies of the same signal and will only send the most recent on the next cyclic transmission.  Which is why you are only seeing the second “CmdByte”.

[William_Griffin]

Hello Stephanie,

You've certainly made some good points about why some of these solutions didn't work. For instance, I wouldn't necessarily expect two sessions to be able to write to the same frame. I went ahead and tried it in an effort to pre-empt any responses that would suggest that it should work. All the same, your explanation of why this didn't work makes sense to me.

>> As to using different modes with NI-XNET, the documentation says it is possible for single signals but I do not think it will be possible with multiple multiplexed signals.

I would still expect that it should be possible to write different modes of the same message. It is commonly done in industry. It seems strange that this functionality would be ignored by XNET. If you can only send a single mode value of a multiplexed message, then what is the purpose of having multiplexers? You wrote that you "do not think" it is possible. Is there anyone at NI that understands this issue and could say for certain with confidence?

>> It may be worth first checking the time interval between writing the two signals and also the speed at which they are read. As you can see, transmitting multiple signals this way with no queue poses the issue of lost data if all time intervals are not manually taken into account.

Maybe I am not clear on what you are suggesting, but if you look at the code a little closer, I think that you will see that timing is not a problem. The database specifies the repetition rate for the messages. In this case, the messages are set up to repeat every 0.1 seconds. The write inside the case structure only updates the corresponding values. It does NOT send the messages. As such the loop rate is effectively set by how often the read finishes. The read is set up to read two messages (this is not a "Signal Single-Point" read). With the messages coming out every 0.1 seconds, that means that this loop is effectively iterating once every 100 ms. This is way more than enough time for this code. We could be reading much faster if we wanted to. Unless I am misunderstanding something major, this code should not be losing messages.

In reviewing your concern about the timing, I did notice an issue with the case structure. I had meant to set it up to read the "Signal Out Data" control every 100th iteration, but I got the true/false cases mixed up (this seems to happen every time!). Since that logic is unnecessary, I have simply removed it. I have re-posted the code and the picture.

As I mentioned previously, I am still looking for a solution to this issue. Any additional thoughts in that regard are very welcome!

[William_Griffin]

Issue summary (with minor edits) from my colleague (Dillon G):

We expected similar capabilities from the new NI-XNET platform as the older NI-CAN platform.  In particular when working with multiplexed (mode dependent) messages.  However, we identified limitations when working with multiplexed messages and as such were not able to configure multiple messages, which shared the same arbitration ID, to be sent periodically from the same session object.

National Instruments R&D has identified and referred to the behavior that we have requested from NI-XNET as being a feature of the old NI-CAN platform.  In NI-CAN this behavior is referred to as "Message Multiple Frame Distribution". The feature is described in the NI-CAN manual (found here: http://www.ni.com/pdf/manuals/370289n.pdf) on page 6-23.  Either the “burst” or “uniform” functionality described in this document would be sufficient for this particular application, however, neither is available.

While the NI-XNET platform supports a compatibility layer for executing the legacy NI-CAN API on the newer NI-XNET hardware, the feature identified as “Message Frame Distribution” is not available through this support.

This leaves us with two options.  Option 1, to switch away from hardware timed periodic message transfer and deterministically time our own messages, but losing the hardware timing which would otherwise be available.  Option 2, switch back to using the legacy NI-CAN platform.

As a side note, this issue could also cause limitations when working with NI-VeriStand.

We are currently working with National Instruments in the hope of getting this functionality added in the future.

[TiBr]

I cant send multiplexed signals too. Is there a solution available since 2012?

[tolltroll]

Hi TiBr,

Since this post is six years old and hasn't seen any recent activity, I'd recommend you create a new thread and post your question there to make your issue more visible to the community. You can reference this post to give further context in your problem statement.

Regards,

Nick

Applications Engineer