Troubles using a serial port on cFP-2020

[Olaf_Stetzer]

---

@ching P. wrote:
Hi Olaf,

This error can be due to several different causes.  One of the most common reasons for this error is that you are not using a proper resource name for your instrument.

Other reasons for that error are described in the following KnowledgeBase Articles:
Buffer Size Error -1073807298 With TCP/IP Communication
Error -1073807298 When Using a Third Party USB-Serial Adapter
Error -1073807298 with a Third Party Instrument Driver

Please take a look at these documents and let me know if you have any additional questions.

---

Thanks for your suggestions but I can easily exclude all of the above mentioned problems. I have problems with a serial RS232 device directly connected to the cFP-2020 and I am using only VISA and serial library functions that are provided by NI. It also seems that this error only appears occasionally which speaks against a wrong resource name.

Cheers,

Olaf

[Ching_F.]

Hi Olaf,

What version of NI-VISA are you using?  You can find this under the My Systems >> Software Tab in Measurement and Automation Explorer.

According to the first link I provided, this error could be a result of using an older VISA driver.

[Olaf_Stetzer]

---

@ching P. wrote:
Hi Olaf,

What version of NI-VISA are you using?  You can find this under the My Systems >> Software Tab in Measurement and Automation Explorer.

According to the first link I provided, this error could be a result of using an older VISA driver.

---

I am not at work but from memory I think it was VISA 4.0 and RT-serial 3.1. The ones that came with 8.20. I updated everything with MAX to the latest versions available on my PC. What I do not know is, if the same versions are used for compilation of the LV-code on the PC before deploying. I could not find out against which library versions a certain vi is compiled.

Olaf

[Ching_F.]

Hi Olaf,

If you installed the latest drivers from your PC onto the cFP controller, your VI should be pulling from the same VISA library.

One other thing to check is to make sure you are using the correct baud rate for your instrument and that you have the appropriate wait between sending commands to your instrument.  It could be that the instrument is not able to handle commands as fast as you are sending them.  Since you only error out sometimes, this may be the culprit.

Please let me know if you have any additional questions or concerns.

[Olaf_Stetzer]

---

@ching P. wrote:

Hi Olaf,

If you installed the latest drivers from your PC onto the cFP controller, your VI should be pulling from the same VISA library.

One other thing to check is to make sure you are using the correct baud rate for your instrument and that you have the appropriate wait between sending commands to your instrument.  It could be that the instrument is not able to handle commands as fast as you are sending them.  Since you only error out sometimes, this may be the culprit.

Please let me know if you have any additional questions or concerns.

---

Thanks for your further suggestions. With some minor tweaks to the latest proposed version/idea here it got the code running again! As far as I can tell it seems to work stable except for some conditions under which the fieldpoint is very busy but it doesn't  crash the code, it only corrupts data for one or two read cycles which is OK. I still plan to improve the whole software performance-wise to avoid these situations as best as possible. Thanks again for all who helped in the last weeks/months with contributions to this discussion.

Olaf

[Enrico_Segre]

Hi Olaf,

I'm just about to undertake the programming of a MCA8000a, and ran into your recent posts. Basically, what I need to do is to adapt a simple LV application I wrote for another MCA card to use the MCA8000a instead. The application is not time critical, and will ultimately run on a desktop pc under windows. Interoperability under linux could be a marginal bonus, which I could give up for the moment. Therefore, I just thought that writing a minimal driver based on the PmcaDll.dll provided by Amptek was the standard way to go. I think I already have a fair amount of experience in interfacing with odd devices, unpacking funny data structures and protocols and what it takes, but seeing your posts, I realized that building a serial driver from scratch (which would then be portable to linux) might be not that trivial as I thought.

Is there some general word of advice you could give me before I start a dead end? For instance, did you have some success with the amptek dll? What led you to write a lower level serial driver instead (the RT fieldpoint target, I guess)?

Thanks in advance, Enrico

[Olaf_Stetzer]

---

@enrico Segre wrote:

Hi Olaf,

I'm just about to undertake the programming of a MCA8000a, and ran into your recent posts. Basically, what I need to do is to adapt a simple LV application I wrote for another MCA card to use the MCA8000a instead. The application is not time critical, and will ultimately run on a desktop pc under windows. Interoperability under linux could be a marginal bonus, which I could give up for the moment. Therefore, I just thought that writing a minimal driver based on the PmcaDll.dll provided by Amptek was the standard way to go. I think I already have a fair amount of experience in interfacing with odd devices, unpacking funny data structures and protocols and what it takes, but seeing your posts, I realized that building a serial driver from scratch (which would then be portable to linux) might be not that trivial as I thought.

Is there some general word of advice you could give me before I start a dead end? For instance, did you have some success with the amptek dll? What led you to write a lower level serial driver instead (the RT fieldpoint target, I guess)?

Thanks in advance, Enrico

---

A short answer to your question: The reason why we could not use the provided dll is that this cannot be used on the fieldpoint, otherwise we would have done that. Our driver is tuned to what we really need and rather incomplete, so I am afraid that it might be not very useful for you but if you are interested, I can provide you our vi's. Maybe you can improve them and send them back to me later so we can both have a benefit. Please contact me privately if you are interested.

Olaf

[Enrico_Segre]

Hi Olaf,
thank you very much for your offer. I have to say that in the meantime I have undertaken the job of building VI wrappers to the provided dll functions, and within a few hours I've smoothly done some 25 of the sync calls, including error messages, nice icons and whatnot (it was just so straightforward to copy each one from the previous). This makes me confident that by tomorrow I could find myself with the almost complete library (I do only sync, I don't think there would be a point in doing the async calls, for labview can handle threading itself), even without having originally aimed at it.  For my present application that will probably suffice; my only problem with the ddl so far is that I can't use it on a nonwindows target, but this might not be even needed. In case not so, it is quite possible that I come back to you, eager to complement and share experiences.
Best, Enrico