Is there a way to get several serial data lines to poll and respond quickly?

[dj143]

I have a PCI-485/8 card where I need to use all 8 ports. Attached is the vi that I�ve developed so far. It works well when there are only 1 or 2 ports. But it really slows down the calling vi when I get up to 8 ports. The Read Delay is intended to set the polling pace, which is used to set the data logging rate. The calling vi is a timed while loop where dt = 0. Due to constraints of the polled device, I cannot set the delay less than 1200 mSec, so it�s set to 1500 mSec as a safety margin.

The poll string is !!SS0n where n is the address number and must be followed by \r\n. Because the poll must be terminated with \r\n, the termination character (for the VISA Configure Serial Port function) cannot be A or D (hex). Otherwise it sees it�s own poll, terminates, and then ignores the responding string. (The polled devices works from RS-485, 2-wire.) As a secondary question, I�d like to know if there is a way to have it ignore its own poll string. But the bigger issue is that it�s dreadfully slow (i.e. around 10 seconds) with all 8 ports configured. The goal is to have this thing run at a consistent 1500 mSec.

Please note that I may be approaching the program from a wrong direction and I�m certainly open to use a better way. For example, it may be more appropriate to obtain the data continuously instead of using a polling scheme. The devices being polled is capable of sending data continuously. However, I choose to use the polling method for three reasons. 1) The device does not send data at a continuous rate. (They are slow and not particularly stable.) 2) The provided data string is not consitent. The string varies in length, which may be the cause of the first problem. 3) There is a project scheduled where I will need to poll at least two devices on each port. (I realize that will really slow things down, but I�ll cross that bridge when I get there.) In other words, I�m open to set the devices on the ports in continuous mode if that�s the only way to get a fast and consistent system.

The application is for an off-shore oil rig where they want to monitor and log data from 8 winches that operate the anchor lines. I�m using LV 7.1, Win2000, NI-Serial v1.6. Please advise�

[johnsold]

Split this into 3 VIs. The first configures and opens the ports (everything to the left of the VISA Writes). This VI executes before the timed loop starts. The second is in the polling loop with the Error lines passed via shift registers. This includes the Writes, Bytes at Port, and Reads. The VISA Close and the analysis are in the third VI (outside the timed loop). This prevents the program from initializing and closing the ports repeatedly, which may take much longer than you think.

Also, I would put the Reads inside a Case structure that only calls the read if Bytes at Port > 0. Some devices do not like zero byte reads.

In the end product you amy want to analyze errors programmatically and attempt to close and re-open a port with an error rathe
r than having the Error Handler holler at the user.

With Bytes at Port do you really need the delay?

Lynn

[dj143]

No, with Bytes at Port the delay is not required. The delay was placed where it is due to previous programming efforts and was left in place to set the pace for data logging. If I remove the delay sequence, what will set the polling pace? What should set the polling pace? Should I remove the delay sequence and set the calling vi (timed while loop) so its dt = 1500?

[johnsold]

Without the delay the pace will be set by the response of the remote device. If the device starts sending as soon as it can after receiving a command, then the Bytes at Port will cause the program to start collecting data as it comes in. Concatenate the incoming data to a string (in a shift register) and then you can search for the /r/n termination without worrying about what the port hardware is doing. Turn off the termination characters in VISA.

Put a short delay in each loop to allow LabVIEW's scheduler to let other parallel loops to run. This delay could be on the order of the time it takes for one or two characters to be sent, i.e. baud rate/10.

Lynn

[dj143]

I removed the delay sequence and set the dt value in the calling vi�s timed while loop to set the logging pace. The result is a reasonably fast and more importantly, stable system. Again, the original reason for the delay sequence is due to a learning curve. This is my first attempt at getting a LabVIEW program to use serial ports for data acquistion. I'm intrigued with your comments with putting a short delay in the loops. However, I need to move on to other projects. Your response has helped me very much. Thank you�

[johnsold]

Search the Knowledge Base for Delay in Loop. One useful article is "How Can I Keep One Loop From Starving Other Loops of Processor Time?", Document ID: 11H9O2U3.

This and links from there can explain the reasons better than I can.

Lynn