serial Tx/Rx with PCMCIA card with LabVIEW under Windows, jitter query

[bmann2000]

I've like to communicate with a RS-422 peripheral device using a laptop.  I figure I can use a PCMCIA card fitted to a COTS laptop, e.g. b&b electronics sell such a PCMCIA card for <£200, it has a max baud rate of 921.6 kbps (NI USB-485 may also be suitable).  My max message length is 24-bytes and I need to transmit and receive at 400Hz.  It’s clear the hardware will be suitable, my question is, will LabVIEW running under windows be capable of achieving 400Hz Tx/Rx without the jitter exceeding about 5mS? No messages received for 12.5mS and the peripheral will terminate the handshake.  I would expect the GUI to allow new messages to be manually entered and received messages to be displayed at a refresh rate of 1Hz or better.  I would also like to implement a data logging facility at 400Hz for periods of up to 5 minutes.   I’m concerned that windows could introduce excessive jitter that would cause the link to time-out and disconnect.  Can anyone confirm they have successfully implemented a similar design without excessive jitter? Can you change windows setting to prevent nuisance interruptions?

[Ben · Accepted solution]

I can not confirm it will work without knowing more about the interaction.

I have managed to collect relaiably at 1KHz using timed loops.

As far as minimizing interuptions... let  me quote myself from this thread.

---

Since this code work most of the time, we should see if there are other things with the OS that could be causing it to forget about your app and make it go off and waste its time. Here are some ideas.

1) Set Windows to optimize background services.
Windows by default will attempt to optimize its scheduling to make foreground processes perform well. For single threaded applications this is fine but for LabVIEW, some of its background threads can suffer.

A) Start >>> Control Panel
B) Open "System" and choose the "Advanced" tab
C) In the "Performance" section click "Settings"
D) On the "Advanced" tab in the "Processor Scheduling" section select "Background Services"
E) Save or apply everything.

2) Stop Indexing services.
Windows will by default do file indexing. File indexing is functionality that tells windows to maintain in memory a cache of files on a disk or in a folder. This makes files show up in the Explorer faster and also makes searching for files faster.

A) Start >>> Accessories >>> Windows Explorer
B) Right-click C: drive and select "Properties"
C) On the "General" tab un-check "Allow Indexing Service to Index This Drive for Fast File Searching"
D) Save and apply everything

3) Set LabVIEW priority in Task manager. Windows will by default treat all processes that are ready to run as peers and will share the CPU evenly.

A) Open the Task Manager and select the "Processes" tab.
B) Locate "LabVIEW.exe" in the list of processes.
C) Right -click "LabVIEW.exe" and choose Set Priority >>> High
Note: Setting LV to run at higher than "High" will put it on equal footing with interrupt service routines etc. This could result in the machine "locking up" because LV is using all of the CPU and there is no opportunity to respond to interrupts from your mouse moving.

4) Shutdown Virus Checking. Virus checking gets its hooks into everything!

5) Disconnect Ethernet cable. Ethernet traffic requires intervention by the OS. No cable, no traffic, no distractions.

With all of that in-place watch your Task Manager while the "problem" is occuring. If the CPU drops off, and you see the LV process is page Faulting, then memory allocations is definately a suspect.

If the CPU spikes, this may be due to the work required to graph the data. If disconnecting the data from the graph/chart eleminates this issue, concider using "defer FP Updates" before updating the indicator.

Does any of the above help?

Ben

---

Now for a wild guess...

Have one loop due the transmitting and let another loop handle the reads.

Also check the async vs sync setting for the VISA R/W functions.

I hope that helps,

Ben 

[bmann2000]

okay, 1KHz has filled me with confidence.  Were you timing in software only? and would you have been aware of any jitter in the data?

[Ben]

---

@bmann2000 wrote:

okay, 1KHz has filled me with confidence.  Were you timing in software only? and would you have been aware of any jitter in the data?

---

I actually canked that one up to 2KHz and it ran for an hour with out missing any iterations. I don't recall what the jitter was.

That app used a hardware clock for the timed loop.

I was not reading from serial but rather from SCRAMNet and recording the "state" at 2KHz.

The timed loop grabbed the data, time stamped it and then passed it to queue for the rest of the code to crunch.

I did do a 100Hz back in LV 6.1 but in that case i was using a RT system to do the queries and a windows system to monitor the replies.

The issue I would concentrat on if your challenge was mine was OS and buss latencies.

If all else fails put the plooing code in a sub-VI marked as one notch below Time Critical (Time critical will stop your mouse) to keep the queries periodic.

Have fun, report any finding so other can tred your path.

Ben

[bmann2000]

it sounds fairly low risk to acheive 400Hz, I'm worried about cost overrun and the possibility of having to resort to RT.  I think hardware timing would be less risky, are you aware of any laptop products that are well suited for timing off?   I'll keep you posted on the results.

[Ben]

Note:

I can not guarentee it will work for you!

If the code is other than ideal, all bets are off!

Don't wimp out the serial device. A cheap widget connected to USB 1 port, again a no-go.

I would think that any of the low end USB widget could provide a good clock source.

I think most any modern PC not running a simualted OS could handle the job. If you have a PC with a serial port, you could test out your code and design ahead of time by connecting an O'scope to teh transmit. If you can't get the determinism you need with abuilt in serial port, then don't bother with the fancy hardware.

Sanity check question

Have you rulled out implementing a comm design that will reconnect if there are interuptions?

Ben

[bmann2000]

Thanks for the advice, I appreciate it's impossible to give a guarantee, but a second opinion is always valuable.  With regards the inbuilt serial port of a laptop or PC, I was always under the impression these maxed out at 115Kbaud, hence my jump up to PCMCIA.  I think LabVIEW and the PCMCIA card will handle the task just fine, I’m worried that Windows screws it up for me, hopefully all the settings you have suggested will keep Windows in check.

The peripheral end terminates the connection after 5 missed messaged, unfortunately this cannot be changed, when it times out something very heavy moves, I’ll need to keep people out the way.

[Ben]

---

@bmann2000 wrote:

Thanks for the advice, I appreciate it's impossible to give a guarantee, but a second opinion is always valuable.  With regards the inbuilt serial port of a laptop or PC, I was always under the impression these maxed out at 115Kbaud, hence my jump up to PCMCIA.  I think LabVIEW and the PCMCIA card will handle the task just fine, I’m worried that Windows screws it up for me, hopefully all the settings you have suggested will keep Windows in check.

The peripheral end terminates the connection after 5 missed messaged, unfortunately this cannot be changed, when it times out something very heavy moves, I’ll need to keep people out the way.

---

Please keep us updated on anything that helped you meet this challenge.

With people, involved, I would be reaching for a RT solution before breakfast.

Keep em safe!

Ben

[bmann2000]

I eventually opted for a CompactRIO solution, you get the RT OS at fairly low hardware cost, (I already have the required software products).  The throughput of messages described previously have been a challenge to achieve on the cRIO-9073 with 266MHz processor, if anyone is sizing a similar system go for the 400MHz cRIO.