Method to test the DIO's on a 6221 DAQ

[dacad]

I use several 6221 DAQ's (PCI and USB) in my systems and there is one that has become suspect.  It is used to control a semi-automated assembly fixture that also required operator interaction. It uses an SCC-68 to interface to the equipment.

I use a DIO to control an air control valve that opens and closes a clamping arm.  The operator is required to press two palm buttons, wired in series, to activate the DIO and therfore the clamp.

Over the past 6 months or so, the clamp has begun to close on it's own. Being a safety issue, this has high visibility.  However, performing a corrective action cannot immediately be verified as it is so intermittent. It can take 2-6 weeks before it shows up again.  I have adjusted the speed of the clamp to a crawl when closing via a flow control valve so the operator has plenty of time to move their hand should the clamp begin to close while they are loading the fixture.

Corrective actions in order performed:  1) replaced control valve,  2) replaced palm buttons,  3) replaced all wiring between palm buttons and the SCC-68 interface w/ shielded wire and grounded the shield leads,  and 4) replaced DAQ today.

All corrective action were completed after the clamp closed on its own after the previous corrective action.

Prior to C/A 3, I personally reviewed the system almost immediately after the clamp had closed on it's own. It was left in an as-is state.  What I discovered was that the code itself had progressed to a point as if the palm buttons had been pressed and waiting for the next operator action, in other words, the DIO had gone true without the operator pressing the palm buttons. The code is basically sitting iin a for loop waiting for the operator to engage the palm buttons or select exit from the UI.  There are only four actions that will cause the program to exit the loop, pressing both palm buttons, selecting exit on the UI (returns to mani screen), selecting calibrate on the UI (opens a small window allowing an air pressure to be calibrated) and service mode (navigates to a screen that allows manual control) but only one will progress the application to run to the  next point of assembly as it did and that is pressing the palm buttons.

This led first to the theory that perhaps there was enough interference from an adjacent wire to energize the DIO (hence C/A 3) and after this that perhaps the DIO circuit itself could have become 'weak' and could self activate on rare occasions, thus C/A 4.

My question is, is there any method to test the actual DAQ to try and determine if the DIO channel has an issue?  I will not be able to use this card in any system that generates a condition that could become a safety issue should the card malfunction in any way.

Any assistance on this is greatly appreciated.

[crossrulz]

What is sourcing the voltage for the buttons?

The 6221 has some pretty weak pulldown resistors built in.  So noise could very well be your problem.  Assuming your 5V source for the buttons can handle it, I would add an additional pull down resistor.  I normally see something around 1kOhm (the built-in ones are 50kOhm typical).  By lowering this pull down impedence, noise will become less of a factor.

As far as testing, I just use the test panels in MAX and apply/read the voltages as necessary.

[dacad]

I am using an external voltage source on this so it should handle the additional resistor no problem.  This power supply could also be a bit noiser than the built in one so that might be a contributor but this thing has run for nearly a year before it started showing the problem.

Was hoping to set up some kind of stress test on the board that could run it until a DIO did something it was not supposed to and be caught by the app.  That or if there is a low level inspection that can measure the function of the DIO's to see if they are 'in spec'

[RavensFan]

I would consider rethinking the application some.  Don't rely on just the DIO's to function properly to determine when to execute a dangerous command.  Use safety rated relays or PLC systems to do that.

Let the DAQ card determine when buttons are pushed and to advise a device when it wants to execute a clamping command.  But put the actual control of the clamping process within these special safety- rated relays so that the clamp only occurrs when the buttons are pushed AND the system tells it to.

If your system right now is such that a clamp command can happen even if the buttons aren't pushed, then it isn't safe enough.

[AnalogKid2DigitalMan]

If you can get a 2 pole contact sets on each palm button, wire each set in series. 1 set sends a signal to an input of the DIO to tell the program both buttons are pressed. The other set in series gets wired in series to the digital output or power source to fire the clamps.

-AK2DM

[dacad]

Yea, wiring in double redundancy would  be a prudent path.  Will certainly discuss that with the folks on this side. If they decide to migrate to the touchless IR type finger switches that we have begun to use though that may not be an option. They are a straight npn type control and they are way more ergonomic (A very scrutinized topic here) and longer lasting than mechanical palm buttons. 

Perhaps wiring the two buttons into two independent DIO's and forcing both to be true to operate the clamp?

I still need to determine the root cause of the problem though, otherwise it could be lurking around in other equipment waiting to pounce.  Since it takes so long to reproduce, it is not  something I can hijack the assy line  for so This is why I am looking for a way to test the daq offline.

Note that the application itself cannot cause the clamp to operate without operator input. There is definitely an anomaly occurring and this is what I need to chase down.

This is the code I am using in the loop (broken due to being on a computer without the drivers)

So I actually had too many functionsliste before that could exit the loop (was thinking of a different loop.  A bit loopy today I guess)

Exit Assy Mode and Stop Assy are front panel buttons that are mouse driven. Stop Assy is greyed out at this stage (should actually remove it from the loop) and Exit Assy exits the entire assembly process.  The only function that will continue and clamp the part is the Operator_Buttons task.

The clamp does not close immediately upon entering this loop but rather at some random point while the loop is looping when the operator is performing some other prep work or at least in two cases, actually loading the fixture.

The safety issue I can fix.  Finding out what is/was (hopefully was) the root casue is what I need to figure out.

[RavensFan]

What I'm trying to emphasize is don't rely on PC-based controls where safety is concerned.

[dacad]

---

@RavensFan wrote:

What I'm trying to emphasize is don't rely on PC-based controls where safety is concerned.

---

I did get that.  It's just not as easy as turning a switch and making that change to the equipment. Access to equipment, time retraints, cost restraints, fire of the day, fire of the hour, working for a company whose key approach to business is being reactive rather than proactive, etc.

As I said, I can address the safety aspect of this and will make improvements appropriately.  My main goal with this thread is still to determine how I can test the daq to see if I can reproduce the anomaly.  Safety aside, if a DIO on the daq is misbehaving, then the potential is for any DIO on any daq to misbehave and this could have an impact on the assembly and more importantly, the testing of all product that is performed on a LV based system.  The liklihood of being able to ship non-conforming product just increased by some small percentage and I have to be able to monitor or be able to test for that.  It is adding another root cause entry to the list of things that can cause a process to operate out of control or test inconsistently.

As a Mfg Engineer, it is my responsibility to make sure the manufacturing equipment and processes add as little variablity as possible to the final product.  My approach is that all variability should be in the product components.

So if I have a daq that has a suspect DIO channel, I need to be able evaluate that to determine if it indeed is causing an issue (safety or not) and what I need to do to resolve that issue.

I will try and spend some time searching other areas of the ni site today if time permits.

[Jacobson-ni]

Doug,

If you have a suspect channel, have you tried to control your air control valve from a different channel?  Additionally, you could compare the signals you are seeing in LabVIEW to a benchtop oscilloscope.

All the other posters are definitely correct about adding redundancy to your system, but if you have a suspect channel you will need to compare that signal to another device, another channel on the same device, or a benchtop instrument to determine if the device isn't functioning correctly.

Best,

[dacad]

I have access to a o-scope and when I am able to find the time, will do some probing to see if I can discover anything.  Because the anomalous condition has been so very intermittent, I would like to find a way to run some type of automated routine that would record results so I can look for a glitch in any resulting data.

I have changed the daq and am now monitoring the fixture itself but without knowing the root cause, I cannot say I have solved the issue.

Same with adding the redundnacy.  I totaly agree it is the correct path to take but it addresses the symptom, not the problem.  If this same phenomenon were to start affecting my assembly or specially testing and is not detected, it could cause non-conforming product to ship.