Fieldpoint I/O Latch Problem

[DL84]

Hello,

Was a little torn between placing this in the LV vs. FieldPoint forum.  Since its a programmatic change that induced the problem, thought I'd post it here!

I have 12 I/O channels that are just digital I/O outputs. (Each one controls a light bulb.)  I recently upgraded to 8.5, and in the process I changed how the I/O were written.  Previously I had 1 large While loop, with 12 channels being written randomly, based on 12 locals.  Yes, bad on many levels.  Now its a bit less random, and more controlled. 

I've attached a picture of the new loop thats controlling the channels.  (Yeah, the variables need to be named uniquely...its next)  Each of the green/yellow/red are all different variables, just named the same..thats why it appears there are 4 of each color. (Otherwise no need for duplicate locals!)

Anyhow, the behavior of the lights have changed - About every 7 seconds a light flickers real quick as though a 0 was being sent out each time its refreshed.  I have set a probe on the lines and the lights should stay on constantly.  None should ever flicker like that.  Its periodic though, every light does it...so imagine all 4 green lights are on...it checks each one as we iterate...number 1 will blink...then 2, then 3, then 4.  It takes about 7 full seconds to go through the entire set.  I can control the flicker length by the Wait(ms) inside the loop, but even at its fastest with no wait...theres still a very fast flicker.

Any ideas what the heck is going on?  According to the probes...they never change value.  The only other important thing I can think of is that prior to this change we were using a direct serial connection....now its over our company network.

Thanks!


Message Edited by leachdor on 03-13-2008 01:17 PM

[MarkBlack]

What is the hardware you are using?

[DL84]

The cFieldpoint unit is a cFP-180x
The module being used is a cFP-DO-403

Just to reiterate, the problem was never there before, we had no "blinking" at any time when the I/O were constantly on.  The only change was from a serial connection to ethernet; and that one programmatic change of the big WHILE loop to the FOR loop.

[JeffOverton]

It sounds like your locals are giving you a race condition.  How are the locals written to?  Latched controls, set by a program, etc?

[DL84]

They are written sequentially in a FOR loop using indexing arrays.  None are written in parallel to create race conditions...

Also, each variable is only updated from one location.  Even *if* we had a race condition of all the channels, all of the addresses are unique and used only once.  So given a random update sequence, it wouldn't really matter which wrote first since no other variables are writing to each channel I wouldn't think.

[JeffOverton]

Hmm.  The only other thing I can think of is that writing two Trues in a row to the DO-403 might have a hardware blip (like the "write true" includes a quick voltage rise from ground to high).  I haven't noticed it in the 403s I'm using, but mine are set to actuate valves, so it's a fairly slow process.  A way to check this would be to toss some shift registers in your loop and only write when the value actually changes, but I have no idea how likely this case is.

[DL84]

Jeff your thinking exactly what I was thinking.  I set up a quick program, just a sequence structure in a while loop with multiple writes, and a delay inside the while.  I've found that passing the same value into multiple FPwrites DOES NOT cause a blink...BUT!! the blink becomes determined by the "Wait(ms)" time I set.

I've been talking with NI for a bit now about this, and they are saying its looking likely this could be a "showstopper bug".  I'm not entirely sure what that means but it sounds bad lol.  Doing some testing back and forth with them now.

[DL84]

Are you writing values over ethernet?

If you have a free channel out of those 15, think you could see if you get the same results I get?

I posted the code below that I'm using thats the most simple way to cause the blip.

I was wrong though I think I mentioned the delay in the while loop determines the blip length.  I could have sworn thats what was happening before the weekend, but its not now.  Still have the blip, its just a very quick one.  According to MAX the value never changes, I'd bet with it going that fast it may not even show up on the LED indicator on the 403 module.

[JeffOverton]

The error didn't occur on my system, at least on the status LED.  However, my system is on a local ethernet, not a company wide network.

[DL84]

Hmm I'm not sure what to think then...I don't get an "error" light on the unit either.  If it was just simulated (no load, and watching the indicators on the I/O module itself) I'd never know there was a glitch.  According to labview, and MAX...there is no 1-0-1 transition....but the light bulbs connected to the I/O disagree.