Simulating CAN with NI-XNET

[AHHHHHHHG]

Using NI-XNET, I am trying to create the data that would be packaged into the frames and sent to the CAN Bus from different sensors. I don't seem to understand why it is handling everything other than the data manipulations, the scaling and offset,  that I have specified in the database dynamically.

Is every card able to just support the reading or writing of one sensor?

I am trying to make a VI that will simulate a bunch of sensors communicating to an ECU through a CAN bus. If the user is able to specify the data that the sensor would be giving the ECU through the CAN bus, and the database is set up, how would I make it so that I can write the correct signal depending on the frame that is chosen from the user input.

I guess to better explain this....

Suppose that we just create a loop back and read on one card, and write on another card... The user would be able to input and see the raw real world values for the sensors in the main VI. So, say that one of the sensors is reading in temperature values, then they are going to be able to input a decimal number and that willl be converted to CAN and thrown into the CAN Bus. Since llwe are looping and reading exactly what we are writing, we can see in the same frame we wrote, which just comes through and can be monitored using the NI-XNET Bus Monitor, simply as a sanity check....Suppose that there is another sensor on that same CAN Bus that the user can give real world values to in the same fashion as the temperature sensor...

1. I am trying to mimick a bunch of sensors on a CAN bus going to an ECU, but want the user to be able to set the values of the data the sensors are giving to the ECU through the CAN Bus, all using the NI-XNET API. The API doesn't seem to handle the scaling and offset that you give it in the database while you are writing to CAN the real world values that the user inputs. Anyone know how to do this and have the API handle the data being packaged correctly after you have the database set up, with respect to the scaling, offset, bit order and bit sizes, just working from the user's input which would be decimal values.

2. I have an ECU with two busses, of which each bus has several sensors attached and communicating. How is NI-XNET working arbitration? How can I have those multiple sensors create this network? Would I require a card for each sensor reading and another for each writing to CAN? What of the diagnostic information packages?

3. If a sensor can be told to use the reading of another sensor, like overriding the temperature of a damaged sensor for the reading coming from another sensor, how would that be done?

4. How are diagnostic packages handled when they are supposed to be requested?

Just for clarification, attached are using the API and is only accounting for one of the many sensors on the two busses on the network talking to the ECU.

[AHHHHHHHG]

Also, what is being transmitted with Frame Raw? The payload itself? Or is there more than just that being outputed from reading CAN block set to Frame Raw?

Is there a way that I can feed in the real world value signals and get the CAN frame constructed correctly through use of the API without having to do anything at the low levels? I can't seem to find anything that will do this.

There is a conversion block in the NI-XNET API, but it will not run with any combination of blocks or signals. Someone posted a VI in another topic trying to replace signals, but this VI didn't seem to work and regardless of that, the inability to use the conversion block aggrevates the problem. If you are working at the frame level, it will return to you the array of frames, but then, what if you want to access the signals themselves within the frame, when the session is using the frames? I get an error due to the signals not being available because the XNET session is using the frames. Can you not use both at the same time to work with the frames and the corresponding signals within the current frame to change the value of the signal through the user's input?

[GPIB_Guru]

I think you want the XNET Signal API and not the XNET Frame API.

To do that, instead of using XNET Create Session of "Frame Out Single Point", you would use "Signal Out Single Point". Then you will be writing the signals and XNET will do the scaling for you.

[estradjm]

Just tried that using a scaled down version of the VI, and there is still no scaling or offset. The same number I put in is the same that comes out in Hex form, without splitting the signal into the respective low and high bytes, without scaling and without any offset.

[GPIB_Guru]

I opened two XNET Examples:

CAN Signal Input Single Point.vi and CAN Frame Output Single Point.vi

I opened the database editor and modified

1. CANEventSignal1 to have a scaling factor of 2 and a scaling offset of 10.

2. CANEventSignal1 to have a scaling factor of 4 and a scaling offset of 5.

Running the two:

I write 0s and read back 10 and 5 (scaling offsets)

I then write 1 0 0 0 1 0 0 0 (for the 8 bytes) and read back 12 and 9 (10+2 and 5 + 4)

So, I am seeing it work for me.

[estradjm]

Alright, thank you. I can get a piece to run, but I have three 5 bit long signals that become two bytes when concatenated together. This is the portion that is not working still. Is this problem because LabView doesn't work below 8 bits inherently? 

Does your CAN Frame and Signal Input Same Port Example VI not run?

[AHHHHHHHG]

Actually, I can get the correct signals seperately, but concatenating them together is proven to be a problem.

I can get the FMI or the actual values of the sensors, but I can't get both into one signal.

[GPIB_Guru]

I am not sure what you mean about concatenating them together. Are they 3 different signals or are they 1 signal that is incorrectly split up into 3 signals in your database?

[estradjm]

It is three failure modes that are supposed to be transmitted in two bytes, or a word, but each Failure Mode Indicator is supposed to be 5 bits long, with what I am g uessing is a zero to pad the space that the 15 bits will not cover within the 16 bits.

The FMI transmits a 2 or 31, of which there are three that transmit to make the 16 bit signal.

I found a hack, but I bypass the API to accomplish this task, which although it functions, takes away from the idea of the API. 

[AHHHHHHHG]

If I want to have multiple frames on a CAN network, how does the NI-XNET API handle the arbitration? How would I set up the timing within LabVIEW? If i want to write to specific frames data from the user's input, how would the API know which frame it corresponds to?