Map Vars to Scalars in FPGA

[miko7985]

Hi all,

I'm new to labview FPGA and i am working with an NI-9871 module. I’ve successfully implemented communication and can currently receive and assign one variable at a time without issues, 

Now, I need to handle an incoming array of 3 variables, each a signed 16-bit value, I must assign each variable to a separate indicator (with no mixing between them) to be used by VeriStand through the FPGA Custom Device Addon, this addon only supports scalar indicators, not arrays or clusters

I’m looking for guidance on the best for this setup:

• should I handle this directly from the serial port inside FPGA, parsing the byte stream and assigning each variable manually to individual indicators?

• using a target scoped FIFO 

[rolfk]

You are providing very limited information. Since it is a serial communication the speed seems probably low. But how low is it? How many data frames per second are you receiving? Periodically or only after a specific request you have to send out? Do you need to have every value available or is the last valid value received good enough?

If you need time consistent series you would for sure need some form of FIFO, if it is just about whatever the last valid value received was, you can certainly use FPGA registers (aka frontpanel controls on the FPGA VI).

I also don't understand the actual problem you mention. Your protocol obviously has a certain format that identifies what of the three values is where in the data stream and as your FPGA code parses that stream you have to assign the value to the correct FP element. This probably will result in some sort of minimal state machine to process the data.

[ZYOng]

For flexibility, I recommend you use the NI-9871 in Scan Mode, which allows you to make use of NI-VISA driver.

Discover, Configure, and Communicate with NI 987x Modules in Scan Mode

Working with RS232/RS485 Protocol In NI VeriStand

[miko7985]

---

@rolfk wrote:

You are providing very limited information. Since it is a serial communication the speed seems probably low. But how low is it? How many data frames per second are you receiving? Periodically or only after a specific request you have to send out? Do you need to have every value available or is the last valid value received good enough?

If you need time consistent series you would for sure need some form of FIFO, if it is just about whatever the last valid value received was, you can certainly use FPGA registers (aka frontpanel controls on the FPGA VI).

I also don't understand the actual problem you mention. Your protocol obviously has a certain format that identifies what of the three values is where in the data stream and as your FPGA code parses that stream you have to assign the value to the correct FP element. This probably will result in some sort of minimal state machine to process the data.

---

Thanks for the reply, here is more detail:

• Baud rate: 230400

• data format: 3 signed 16-bit values per message (6 bytes total)

• receiving: continuous message stream, no request needed

• message structure: I can customize it (I could add a start byte, header, ID, checksum if needed)

• timing: No exact frame rate required, but messages arrive continuously as stream, and I want to always expose (show) the latest values at the indicator so Model in Veristand could get these values
  
  

Current method:
I can successfully read one byte at a time using FPGA serial port method nodes, and can parse single variables correctly either by

• DMA Send (but accessing the data would be limited from Veristand side, so i will need to De-interleave FIFO at FPGA and assign to indicator)
  
  
• read directly from Port Read FPAG Method, No FIFO
  
  

Problem: Now that I want to handle 3 variables per frame, I need to know the best practice to:
a) Read the 6-byte message reliably
b) Parse each variable cleanly
c) Assign each variable to its own FPGA scalar indicator for VeriStand

Questions:

• Should I handle parsing entirely in FPGA logic, assigning directly to the indicators?

• Would a target-scoped FIFO help, or not needed in this case?
  
  

I was trying to follow the solution in this topic, but is this the best practice for FPGA ?
Solved: how to parse serial data? - NI Community

Thanks

[miko7985]

---

@ZYOng wrote:

For flexibility, I recommend you use the NI-9871 in Scan Mode, which allows you to make use of NI-VISA driver.

Discover, Configure, and Communicate with NI 987x Modules in Scan Mode

Working with RS232/RS485 Protocol In NI VeriStand

---

Veristand, doesn't support, RS485 communication so i used FPGA Custom addon instead of building full custom device for the CRio

Additionally, NI-9871, is not supported for Scan Mode directly to Veristand, so FPGA is the only approach

Thank you

[rolfk]

Your main problem really will be synchronization of the data frames first. Without some extra information you will never know if your datastream is at the first, second or third value and in fact even halfway of one of the 3 values.

Synchronization could be for instance an idle time between frames. If no data arrives for 50 us or so, a new frame has started. That of course means that your sender needs to be able to send the frame as a whole and not byte by byte with random pauses in between.

Detecting if there is any data, and reading 6 bytes as soon as there is, with your byte_read routine should be fairly simple. The detection of > X us break should be not a problem either in FPGA.

And once you have the 6 bytes, parsing them (which is really an expensive word for what you have to do here as there is not much parsing at all to be done) into 3 different numerics is just a little minimal boolean logic.

And since you are only interested in the last received values, no FIFO is required. Just put the result into 3 front panel controls.

[miko7985]

---

@rolfk wrote:

Your main problem really will be synchronization of the data frames first. Without some extra information you will never know if your datastream is at the first, second or third value and in fact even halfway of one of the 3 values.

Synchronization could be for instance an idle time between frames. If no data arrives for 50 us or so, a new frame has started. That of course means that your sender needs to be able to send the frame as a whole and not byte by byte with random pauses in between.

Detecting if there is any data, and reading 6 bytes as soon as there is, with your byte_read routine should be fairly simple. The detection of > X us break should be not a problem either in FPGA.

And once you have the 6 bytes, parsing them (which is really an expensive word for what you have to do here as there is not much parsing at all to be done) into 3 different numerics is just a little minimal boolean logic.

And since you are only interested in the last received values, no FIFO is required. Just put the result into 3 front panel controls.

---

I tried to use the port read directly and got nothing at indicators but here what i did :

• Frame format:
  I added 0xAA at the beginning and end of the frame,
  [0xAA, Var1_LSB, Var1_MSB, Var2_LSB, Var2_MSB, Var3_LSB, Var3_MSB, 0xAA]
  I tested this logic using a constant array in LabVIEW and works fine (I can detect the start and end markers, and assign correct values to indicators)

• Direct Read from Port (without FIFO):

  • I tried using the Read Port method node, reading byte-by-byte into an array and searching for the frame markers (0xAA).

  • But in this case, my indicators remain zero,I suspect this is a synchronization issue (the indicators will only update if the logic detects both start and end 0xAA, so when it misses a byte or gets out of sync, it skips updating)
    
    

• Tried Target-Scoped FIFO:

  • Test A: If I write a constant array to the FIFO (instead of reading from the port), then read back, everything works fine, indicators show correct values at veristand side

  • Test B: If I feed the port read output into the FIFO, I get wrong data on the indicators
    
    

Attached this part of the project

thanks

[rolfk]

Since you use binary data (a 16 bit binary value send as two bytes) having a magic pattern to indicate start and stop of your frame is quite unreliable. The 0xAA value could happen anywhere in your binary data too! If you wanted to go that route you would actually have to start to do escaping too, such as sending the 0xAA twice if it is inside the data portion rather than the frame indication. And your receiver needs extra logic to remove that double 0xAA. Possible but not the most efficient solution for sure.

If your read_byte routine is not fast enough to read every single byte without missing one, things are anyhow much more complicated than you can probably handle on your own. Either the read_byte routine needs to be improved or you need a much more involved data transmission scheme than just sending raw data!

[ZYOng]

FPGA is not the only approach. In fact, it is not a flexible way.

In Scan Mode, NI-9871 can be accessed by NI-VISA driver, as shown in Solved: NI 9871 best way to create customization to veristand

If you want to avoid creating a custom device, you can still use the VeriStand Instrument Addon custom device

Based on your frame format [0xAA, Var1_LSB, Var1_MSB, Var2_LSB, Var2_MSB, Var3_LSB, Var3_MSB, 0xAA], here is the result.

You can import the attached configuration when adding the CD. Remember to change it to VISA.

[miko7985]

---

@ZYOng wrote:

FPGA is not the only approach. In fact, it is not a flexible way.

In Scan Mode, NI-9871 can be accessed by NI-VISA driver, as shown in Solved: NI 9871 best way to create customization to veristand

If you want to avoid creating a custom device, you can still use the VeriStand Instrument Addon custom device

Based on your frame format [0xAA, Var1_LSB, Var1_MSB, Var2_LSB, Var2_MSB, Var3_LSB, Var3_MSB, 0xAA], here is the result.

You can import the attached configuration when adding the CD. Remember to change it to VISA.

---

Thank you

I switched all modules to scan and used VISA in Veristand side but i got error during deployment

I am Sure that all modules now in scan Mode as i when i saw the fault i test the read with an old VISA VI project and worked normally, the issue from Veristand side

NI MaX

Appreciate your help
Thanks