Long delays within cFP RT serial routine

[8bitbanger]

Hi Folks,

I'm attempting to pass some basic serial data back and forth from a cFP-2010 to a front panel over OPC (well, using National's SVE OPC). We currently have a large-scale project that is not using any RT features, just communicating w/the cFP via PSP. Due to FDA regulations, in order to completely convert our project to RT would be a huge undertaking. So I've been tasked with creating a simple 'wrapper' that will allow us to add a VI or two to the main application.

Anyway, I'm having some delay issues on the RT side of things. FYI I am using a terminal/serial port monitor connected directly to the cFP for testing.

From the 'host' (PC) front panel, when I send a string, it *immediately* gets piped out the cFP's serial port. I see it right away in the terminal. However the delay is incurred when I send a string from the terminal program to the cFP. Sometimes it shows up within a second (on the front panel), other times it take 8-9seconds.

I feel I have some problems with the architecture: when I set a breakpoint on the 'target' VI for the 'NumBytes' property, it is not consistent. I am relatively new to the RT enviroment, so please excuse any gross negligence. 🙂

Beyond a simple problem, can you make any suggestions to streamline the communication? I would like to make use of some sort of FIFO, but I'm not sure how to implement it over a shared variable.

PS - you'll notice I am using Datasocket reads/writes on the target. I have not been able to figure out how to reference the shared (network) variable directly.

Kind Regards,

Jamie

[8bitbanger]

Just as a follow-up: I simplified the target VI a great deal.

It now: waits for OPC variable to update, writes to serial port, waits 1000mS, then reads.

Still the same exact response time, even when using a loopback adaptor on the cFP. The user LED indicates if any error occured, of which I get none.

Any thoughts?

Kindly,

Jamie

[8bitbanger]

Well as long as I'm typing to the wind I may as well update the thread.

I've been learning quite a bit about Datasocket and all the nifty names NI has coined for their protocols. It seems like such a huge mish-mash...

Anyway I've moved on to trying the Publish Data on the FP and Datasocket read/writes on the host vi. This seemed to take care of my delay problem, but it may very well have been just a syntax mistake also. While it works OK with a loopback device, it doesn't work so well with the actual end device...

I did discover one alarming thing about logos: it is only *update on change*, which includes the timestamps!!! No matter how many times you Publish data, if the data is the same, the timestamp does *not* get updated, nor does the functionality to 'wait for change' within the 'ReadDataSocket.vi'.

So this almost entirely rules out using these for serial transfer, even buffered. If I get two identical 'polling' commands sent to the FP to send out the serial port, one will be lost.

What is the next best suggestion for queue'ing the DS information? I really don't want to go through the trouble of packetizing the serial data. Is there a way to use the queue functions on datasockets?

Thanks,

Jamie

[Hillary_C_E]

Hi Jaime,

So, there is this Dev Zone on Buffered Data Socket. Additionally, you might want to check this Dev Zone on Intro to DataSocket with FieldPoint and its followup Advanced DataSocket with FieldPoint. Let me know if these help.

[8bitbanger]

Hi Hillary,

Thanks for your response. I thought initially that I could use that queue, but it turns out it wasn't neccessary. What I *did* get from the article was the the use of those flags. Very helpful. Also the devices we are using are quite simple, so there is no need to read each byte from the serial port (the buffer is sufficient).

Anyway, I have attached a working test project. This allows you to TX and RX over DSTC via a front panel. It will need proper error handling and more graceful recovery, but it works.

The looped TX is dirty, but it was just to test.

Please please, I always welcome any/all suggestions, so if anyone takes a look and see's a better way to do something, by all means let me know!

Thanks kindly!

Jamie

[8bitbanger]

PS - I noticed I accidentally grabbed some extra files; The BACKUP was a one-way version, and the 'stateversion' was the beggings of exactly that, a state machine version. The BACKUP certainly works, but I can't say the same for the later.