Re : Transmit a value with a negative number or a decimal point in the xnet payload

[sfrosty]

How would I transmit a negative number or a decimal point in the CAN xnet Payload?

For example, a force level of - 1.5 g or a sound level of 90.5 db? 

Or would I just configure the conversion values in the xnet database?

[ben64]

---

sfrosty a écrit :

How would I transmit a negative number or a decimal point in the CAN xnet Payload?

For example, a force level of - 1.5 g or a sound level of 90.5 db? 

---

You need to set the session to Signal Output Single-Point mode. In this mode you can transmit an array of DBL. Search the XNET help for more details.

Ben64

[sfrosty]

Is that the only way to transmit a double? I was originally setting things up in a CAN output frame stream mode.

If I am to utilize the single point session mode, would I than utilized the signals in my xnet database and than sequentially output the values one at a time?

xnet database xml file attached.

[nathand]

I haven't dealt with xnet databases at all, but using conversion values in the database sounds promising.

The XNET payload is just bytes. It's up to you what those bytes represent. You determine whether to treat each byte in the payload individually or to combine multiple bytes into a single value, and how to interpret those bytes into real data. For negative values you can interpret data as a signed integer instead of unsigned, or as a floating point value (either single- or double-precision), and for decimals you can use a floating or fixed-point value depending on the desired range and precision.

[Hooovahh · Accepted solution]

The data being sent is an array of bytes (typcially up to 8 bytes).  If you want to have a value that goes from -10 to 10 you can do this many ways depending on how many bits you want it to take up.  I think the easiest way to understand it would be to send it taking up a whole byte (8 bits) incrementing by one, starting at -10.  So if your payload is 0x00 00 00 00 00 00 00 00 then you have a value of -10, and if your payload is 0x00 00 00 00 00 00 00 0B then you have a value of 1 (0x0B is 0d11 with an offset of -10 makes it 1).  Or if you want 0.5 increments maybe you still have an offset of -10 but each value increments by 0.5 so a 0x0B is only -4.5.  

There are practically an unlimited number of ways to represent your data and you need to define it by the range and precision you want.  You can then make a DBC, or make a database with the XNet Database editor then reference those signals, or perform the conversion yourself from doubles to an array of bytes using that database.  But using the write signals API makes it much easier.  No need to worry about retransmitting or conversion.

[sfrosty]

Thanks!!! I think I'm getting it? I'm currently creating a CAN xnet app that transmits engineering units from several transducers. The CAN data is to be interpretted by a datalogger (intrepid) through its' CAN interface. The question in my mind has been how does this device know how to interpret the data? If I write signals, can this device convert the CAN data written as signals back into dbl values or is this strictly a LabVIEW function. Do I need a dbc file to write data, or is a dbc file strictly for interpretting data? There are different methods for transmitting CAN data, CAN frame single point, CAN frame Output Queue, CAN frame output Streams, . . . . So, I have to think my first job is to determine what the device I am transmitting data to expects. Am I correct?

Are most CAN devices, like the intrepid configurable, where they are able to accept signals, queues, and streams, or are they specified by the manufacturer?

[Hooovahh]

---

@sfrosty wrote:

Are most CAN devices, like the intrepid configurable, where they are able to accept signals, queues, and streams, or are they specified by the manufacturer?

---

Most CAN devices are not nearly as configurable as the XNet solutions.  Most CAN devices that have some kind of API to control them only support sending and receiving raw frames with no periodic transmit.  This includes Intripid, Vector, Kvasar, CAN to serial, and cheap NI-CAN hardware.  This means conversion from raw frames to signals, or from signals to raw frames needs to be done in software.  XNet allows for a decent amount of this work to be offloaded to the hardware.  Give XNet a database, tell it to send a signal every 100ms and it does it.

So to answer your other question the DBC is used in both directions.  If I am reading data and I just get raw frames (up to 8 bytes of data) what are the signals in it?  How many bits are there?  Starting bit? Bit length? Scale and offset?  This is defined by the DBC.  Same with the reverse.  What if I want to write 5000 RPM to a signal, what frame needs to be sent?  The DBC will convert using the same information (start bit, bit length, scale, offset, etc) to get the raw frame and send it.

[nathand]

---

@sfrosty wrote:

There are different methods for transmitting CAN data, CAN frame single point, CAN frame Output Queue, CAN frame output Streams, . . . . So, I have to think my first job is to determine what the device I am transmitting data to expects. Am I correct?

Are most CAN devices, like the intrepid configurable, where they are able to accept signals, queues, and streams, or are they specified by the manufacturer?

---

You are not correct. Your receiving device sees bytes of data, regardless of which of the transmit functions you use. The only thing that matters is that your receiving device knows how to reassemble those bytes into meaningful values. LabVIEW uses stream, queue etc to distinguish between different functions that all send CAN data, but once the data is on the bus it doesn't matter (and you couldn't determine) which function was used to send it. You can pick whichever function best matches your application. Using a CAN database, you can write engineering values (such as floating point numbers) to a function, and tell the CAN driver to send the latest value periodically. If you want lower-level control, your code can build up the CAN packets and send them explicitly.

[sfrosty]

Thanks for that! Very much appreciated!