Troubles using a serial port on cFP-2020

[Olaf_Stetzer]

Hi,

I have a labview program that worked fine under 7.0 but I needed to upgrade it to 8.20 for several reasons. Now I have troubles using the serial ports on the fieldpoint as I get the following error message:

Error -1073807202 occurred at Property Node in VISA Configure Serial Port (Instr).vi->Serial_test_code_LDT.vi

Possible reason(s):

VISA:  (Hex 0xBFFF009E) A code library required by VISA could not be located or loaded.

The error occurs already where I try to configure the serial port with the following example. I also replaced the VISA resource with a constant and typed COM2 into it which is the port I want to access. I have the doubt that something went wrong when I installed 8.20 and maybe some important part of the RT-Library is missing. From earlier posts to this forum I found that there should be a vi-palette related ot serial ports under fieldpoint which I do not find on my system. If I am correct that soemthing went wrong during installation how can I track this down and probably reinstall the component in question?

Thanks,

Olaf

[Wayne.C]

Olaf,

Two parts of the upgrade.  Development software and cFP software.

Make sure that you upgraded all the software on the cFP to match the exact versions on your development machine.  Pay particular attention to NI-VISA and NI-Serial RT

[Olaf_Stetzer]

---

@centerbolt wrote:

Olaf,

Two parts of the upgrade.  Development software and cFP software.

Make sure that you upgraded all the software on the cFP to match the exact versions on your development machine.  Pay particular attention to NI-VISA and NI-Serial RT

---

Sorry, I totally forgot to answer lately. Since I ran in to this "two-part" upgrade thing before this time I upgraded the Fieldpoint software immediately but still got this problem. MAX showed that all drivers were up to date! But after your response I re-installed everything anyhow and first deleted all old versions on the Windows PC and that did the trick.

Now I have another problem: Another device attached to the same fieldpoint via VISA-serial is now misbehaving. Previously it received all data for a special command (that is 532 bytes, 512 data plus 20 status) but now it always only receives 128 bytes although the VISA-read vi gets the 532 as "bytes to read". Is it possible that some timing or buffering behaviour has changed for the transition from LV 7.x to 8.20? Is it possible that the read buffer has been reduced in size? Does it have to do with the termination char? (but it worked before!)

Thanks,

Olaf

[Wayne.C]

Olaf,

It does sound like you are encountering a buffer overflow.  Handshaking can play a part in this.  I think I would start by verifying whether or not you are encountering a buffer overflow.  Does the 128 bytes that you do receive look like correct data?  Is your vi generating any errors?

From the image you posted, it looks like you are using some sort of handshake during the read.  Is that correct?  Can you post your vi's that configure the port and read the port?

[Olaf_Stetzer]

---

@centerbolt wrote:

Olaf,

It does sound like you are encountering a buffer overflow.  Handshaking can play a part in this.  I think I would start by verifying whether or not you are encountering a buffer overflow.  Does the 128 bytes that you do receive look like correct data?  Is your vi generating any errors?

From the image you posted, it looks like you are using some sort of handshake during the read.  Is that correct?  Can you post your vi's that configure the port and read the port?

---

By looking at the data I can see that the first 4-5 read cycles look reasonable, because the 20 byte status is sent first and looks different from the binaray data that follows. Then there are a couple - maybe 5-10 - more read cycles where data looks strange until nothing happens anymore - meaning no data seems to be received anymore. Regarding the handshaking: I have to look into this a bit more since the original code is not from me and the programmer has left our group a year ago. I will add the relevant paragraph concerning handshaking from the manual at the end of this message. It looks like our code does not do exactly what the manual says but I remember that our programmer had a hard time gettting this running at all after a lot of trial-and-error.....
The configuration is shown in the first image I sent in the last post, the vi is much larger and contains a lot of other stuff which does not modifiy the serial port (only flushing and setting a new baud rate). If it helps I can send it but I am afraid that is does not provide any more information.

The device I am trying to communicat with is an Amptek Pocket MCA (Multichannel Analyzer) which is not easy to program since communication seems to be far from any standards (as far as I can tell). I can look into that and send some more information if neccessary.
--------------------------------------------------------------------------------------------------------------------
PC enters this mode after SEND DATA COMMAND. The sequence to receive a byte is as
follows:
1. Check if there is a byte received by the serial port or if interrupts are used an interrupt is
generated when a byte has been received.
2. Get and store the byte from the serial port.
3. If the byte received is not the last expected byte from the MCA8000A alternate DTR
indicating that the PC is ready to receive data.
4. If the byte received is the last expected byte do not alternate DTR and disable interrupts in
case of interrupt transfer.
The MCA8000A always sends first the 20 bytes of the MCA8000A status structure. If
the check sum of the status bytes is OK the PC may store the status information. After the
status information has been received the MCA8000A starts sending the channel data in packets
of two bytes - the lower or the upper word (see Channel Data and Send Command). First is
send the lower byte of the channel data word. The PC can interrupt the data transfer from
MCA8000A to the PC at any time by setting the RTS line HIGH.
NOTE: MCA keeps sending data as long as PC enables the data transfer from MCA to the PC
by keeping RTS LOW and alternating the DTR signal. Therefore, it is the PC responsibility to
monitor and control the data transfer between the MCA8000A and the PC.

[Wayne.C]

Olaf,

Suggest you start by setting serial buffer size to something like 1K. 

[Olaf_Stetzer]

---

@centerbolt wrote:

Olaf,

Suggest you start by setting serial buffer size to something like 1K. 

---

So I set the buffer size to 1024 as you suggested. Unfortunately this did not change the behaviour at all. One thing I realized when playing around with different modifications to my code: The VISA-serial-read-vi can be set to synchronous and asnchronous I/O. It was previoulsy set to sync. although in the LV-manual it says that for serial ports I/O is async. I dont relly know what that setting means and I tried to change it without a lot of effect. Maybe this should have been async. from the beginning and code optimization has been falsely done with a wrong setting here (being probably very unstable to changes in overall code performance and timing)?????

Olaf

[Olaf_Stetzer]

 

So I set the buffer size to 1024 as you suggested. Unfortunately this did not change the behaviour at all. One thing I realized when playing around with different modifications to my code: The VISA-serial-read-vi can be set to synchronous and asnchronous I/O. It was previoulsy set to sync. although in the LV-manual it says that for serial ports I/O is async. I dont relly know what that setting means and I tried to change it without a lot of effect. Maybe this should have been async. from the beginning and code optimization has been falsely done with a wrong setting here (being probably very unstable to changes in overall code performance and timing)?????

Olaf

---

I already found out that the VISA sync/async settings are different from what it means to serial comm. Some testing gave additional information. Previously the timeout was set to 500 (I guess 500 ms) and I now set it to 10000. The result is that with VISA I/O set to sync the data now looks always correct while there is still only 128 bytes read instead of the expected 532. Since my vi's measure the time it takes for the read to complete I see that with sync it takes the full 10 sec until timeout to read the data. Interestingly, when I set VISA I/O to async. the data looks "corrupted" after a few read cycles. The first few "correct" cycles read in about 1 second while the "corrupted" data scatter heavily but take roughly between 5 and 30! seconds. Still, always 128 bytes read (buffer set to 1024) instead of 532 expected.

Olaf

[Wayne.C]

Olaf,

I suspect the problem is in the read sequence.  I read the spec for your instrument and I must admit this is a very unusual serial interface.  It looks like your program alternates the DTR line based on the timing of timed loop and not in response to a byte being received.  I can not tell from what you posted how fast the loop is running?  If it is running too fast, it may confuse the instrument.  Can you post a bit more of the read sequence?

I would suggest that you modify the read so that you only toggle DTR after a byte that is not the termination character has been received.  The VISA bytes at serial port will allow you to monitor how many bytes have been received.

[Olaf_Stetzer]

---

@centerbolt wrote:

Olaf,

I suspect the problem is in the read sequence.  I read the spec for your instrument and I must admit this is a very unusual serial interface.  It looks like your program alternates the DTR line based on the timing of timed loop and not in response to a byte being received.  I can not tell from what you posted how fast the loop is running?  If it is running too fast, it may confuse the instrument.  Can you post a bit more of the read sequence?

I would suggest that you modify the read so that you only toggle DTR after a byte that is not the termination character has been received.  The VISA bytes at serial port will allow you to monitor how many bytes have been received.

---

I have now written my own read-function which exactly does what the specs say and what you repeated in your reply. In the best case I get 128 bytes, if I play around with timing I get sometimes a more unstable result and less bytes but never more than 128. What puzzles me is that the maximum I get in all cases I tried is a highly "suspicious" number. I really get the feeling that something with the drivers might be broken. I will try to install the most recent version of LV today and see what happens. If nothing changes, I will try the old version of "our" software which worked perfectly under LV 7.X, with LV 8.20. (For the current LV 8.20-software I did some major modifications to the code but I did not touch the code that communicates via serial. So, the overall timing might have changed, but the serial comm code is as it was when it worked under LV 7.0.

Olaf