LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Julabo RS232, FPGA, RT, FIFO

Solved!
Go to solution

Hello,

 

yes the problem even occurs if only FPGA.vi is running.

 

Like you said i tried to test every port so i rewrite the code to update the config of the ports separately. Updating the config of a port which is not connected to any device causes the above mentioned problem. If there is something connected everything is fine. So this problem is not any more struggling me 🙂

 

I changed a few things and finally managed to send and receive the commands from the correct ports. Everything works fine except one problem:

 

Sending commands to the ports is very very slow. So the same commands are written into the fifoWRITE over and over again. If i have new commands to send it takes very long because it is sending the commands which were written in the meanwhile into the fifo.

So sometimes it takes one to two minutes to send a command to the device. I tried to reduce the timeouts of fifoWRITE and Ports (WriteByte) but it didnt help.

 

Would it be helpful to reduce fifo size so there is only enough space for one batch of commands to send?

 


Any ideas?

 

Thanks and regards,

ikkebins

 

 

edit/

find FPGA.vi and RealTime.vi in the attachments.

Download All
0 Kudos
Message 11 of 14
(557 Views)

Let's say you send a command to one port. That one port responds, but none of the others do. Since all of the "Read Bytes" are in the same loop, the loop can't proceed until the timeout occurs on all the other ports. You are limiting the rate at which you read the response to one character every 100ms even though the data is probably received much faster.

 

You are also sending a lot of null data, because on every cycle of the FPGA loop you send a character from every single channel even if the Read Byte for that channel timed out. In this situation, on an FPGA, there's no reason to use anything other than 0 as the Timeout for the Read Byte, but don't write to the DMA FIFO if there's no data.

 

It would also be a good idea to rework to avoid writing to the DMA FIFO in parallel, since your current approach forces the compiler to generate extra code for arbitration.

Message 12 of 14
(549 Views)

Hey nathand,

 

thank you for your help! I implemented your corrections.

 

I found out that if i write into the fifoWRITE every 5 seconds everything is fine, because the fifo is not filling up with "old" commands.
I have to send commands all the time because i want the device to send me back the current temperature.

Is there a possibility to speed up the serial write? I tried to limit FIFO Size. The idea was that the command, which is continously send, is only repeated several times, so if i send a new command it will not take that long. But i think the host FIFO has a bigger memory.

 

Ideas?

0 Kudos
Message 13 of 14
(525 Views)

If the FIFO is filling with "old" commands, then you are probably writing to it faster than you can read responses. I recommend that you not write a new command to a given channel until you receive the response from the previous command on that channel. Alternatively, if you are always sending the same command to the serial port, you could let the FPGA handle that, and parse the response on the FPGA. Write the most recent result to an indicator on the FPGA front panel (instead of to a FIFO) so that the host always has access to only the most recent data.

0 Kudos
Message 14 of 14
(518 Views)