LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Having difficulty controlling DIO96 with a .vi that I wrote

I am very new to LabVIEW and creating .vi files. With the help of several people here at this board, I was able to create the attached .vi to control ER-16s that I have connected to a DIO96.

The funny thing is that it's only the first 8 relays on both of the attached ER1-16s that seem to work properly. On both ER-16s, the second 8 relays have their lights light dimly when I toggle their state. With a continuity tester, I've verified that the relays aren't closing, even though the LEDs light dimly. The first 8 relays on both ER-16s work correctly. The LEDs glow brightly, and the relays close properly.

I can't, for the life of me, figure out why the second 8 relays on both ER-16s don't work properly.

When I bring up the Test Panels in the Measurement & Automation tool, the relays in question DO work properly. The LEDs light up brightly, and the relays close. I'm sure that there must be something wrong with my .vi file...

Anybody have any ideas of what could be causing this problem?

Cheers!
-darren
0 Kudos
Message 1 of 14
(3,435 Views)
First let me commend you on a colorful front panel. Organized well with lines indicating flow, and good instructions on switch operation. However, your block diagram is a giant nightmare! You have wires going all over the place, very hard to trace and to determine execution flow. You should consider breaking it down into modules. For instance, you can create a module to initialize your DIO ports at the very beginning. Once initialized there is no need to initialize again. The module can be all intialization functions grouped together or it can be a subvi. Also, you can create a subvi to convert the boolean switch values to numbers to be written to the port. Call this subvi at the 4 places you have this code instead of repeating the code 4 times. Try grouping your switches so that you don't have wires running wildly. For all the switches in the block diagram, if you right click and uncheck View as Icon, you will have more room to work with.
Now for the problem. Your statement about the relays being off, and the LEDs glowing dimly suggest that there is some hardware wiring issue. If the relay is off, the LED should be off. Check your wiring with a DMM. Find out why the LEDs are glowing dimly. Your code looks like it should work, you use the same code for all ports. Check your port definitions in MAX and compare it to your code. Does DIO Channel 0 consist of lines 0 thru 7, does Channel 1 consist of lines 8 thru 15? Create a small program just to control Channel 1 for the second set of relays, but don't connect the relays. Use a DMM to read the outputs. Look for outputs on lines other than Channel 1 lines to see if there is a channel definition error. It would be much easier to find a problem in a small vi rather than your entire vi. This should point you in the right direction.
- tbob

Inventor of the WORM Global
0 Kudos
Message 2 of 14
(3,420 Views)
tbob,

Thanks for the kind words. You are correct in the block diagram being an enormous nightmare. I was trying to keep the block diagram componentes organized the same way as the front panel. This works fine until you start to wire things up, and then you end up with the nighmare that I created. 🙂

One interesting thing that I noticed while working on this yesterday: Even though the block diagram is a bit of a nightmare, you can see that the portions that control the ports on the DIO96 are on the perimeter (two in the upper right corner, and the other two along the bottom). The banks of relays that I've had the problmes with are on digital channels 1 and 3. I found that if I enclose those portions in flat sequences, that the relays then begin to behave, yet now the digital channels 0 and 4 start to misbehave (light dimly and not flip the relays). Obviously there is a problem with my coding.

Does this help to determine the root source of the problem?

Cheers!
-darren
0 Kudos
Message 3 of 14
(3,411 Views)
You obviously have some type of race condition, perhaps trying to write to two different ports at one time. That is why it is important to re-do the block diagram into something sensible. It is nearly impossible to trace the execution flow as it is, and it will be extremely difficult to find the race condition. By making the block diagram modular, you will probably eliminate the race condition and fix your problem. Perhaps a state machine would be practical here. The execution flow would be much more manageable. If you have to come back to this vi in the future, think of how difficult it would be the way it is now. Take the time and effort to make it modular.
I still think that something is wrong with the hardware wiring. You should never have dimmed LEDs, they should be either on or off. Are your relays the coil and contact type, or are they solid state relays (ICs)? Solid state relays could cause a partial conductance without proper drive that would cause a dimly lit LED.
- tbob

Inventor of the WORM Global
0 Kudos
Message 4 of 14
(3,407 Views)
Thanks for the info on the race condition. I'll re-do the block diagram and make things quite a bit more sensible. I really appreciate your help on this. It's frustrating when you're in the last 1/4 mile of a marathon and just can't quite figure out the cause of a problem.

Cheers!
-darren
0 Kudos
Message 5 of 14
(3,401 Views)
The relays, by the way, are the coil type. They're in the external ER-16 modules. Each ER-16 is about the size of a paperback book. Each relay is approximately the size of a postage stamp and about 1/2" thick. When you change their state, there's an audible click as the coil pulls the relay closed.
0 Kudos
Message 6 of 14
(3,395 Views)
How is it possible that sometimes your LEDs are dimly lit? If the relay contacts are open, how can any current be flowing through the LED? You should investigate this, it may have some bearing on your problem. You should have either the cathode of the LED wired to ground or the anode wired to V+ (perhaps with a current limiting resistor in series). The other side of each LED should be wired to separate relay contacts. When the relay is open, there is absolutley no current flowing through the LED. When the relay is closed, either V+ or ground is applied and full current (limited by resistor) flows causing a fully lit LED. There is no case where the LED should be dim.
- tbob

Inventor of the WORM Global
0 Kudos
Message 7 of 14
(3,386 Views)
Forgive me, I should have pointed out that the National Instruments ER-16 units have LEDs in them that indicate the state of the relay. This is part of the design of their product. There's one mounted on the circuit board LED per relay. When the relay is closed, the LED illuminates. It would almost appear that enough current is flowing to dimly light the LEDs, yet not quite enough to close the relay. When the LEDs are dimly illuminated, I've confirmed with a continuity tester that the relays are not closed.

(Without this little piece of information, yes, it would be very odd that an LED that I connected to the switched part of the relay would dimly illuminate -- in this case, the LED would be either on or off, there would be no dim illumination) -- thanks for your patience, I apologize for leaving out this little critical detail.
0 Kudos
Message 8 of 14
(3,381 Views)
AHA, a clue. I should have mentioned that I was not familiar with the ER-16. From what you have described, I would bet that the DIO port is configured for input (read) instead of output (write). This will cause a high impedence closed circuit. There is a pull up resistor on the input of the DIO when configured for input (reading). The current goes through the pull up resistor and into the LED circuit, causing a dimly lit LED. I am quite sure that the port is configured for input. Change your code to configure all the ports at the beginning of the block diagram before anything else happens. Use a sequence structure if you have to in order to ensure that this config happens before anything else. Then do not use the DIO config vi again. This should clear your problem. By having the config vi all over the place, it is possible that the other DIO channels gets configured to a default state of input when you are actually configuring channel 0 for output. Look up examples on DIO config and use the help feature to find out the best way to configure multiple channels of the DIO for different directions.
If all are output, I think you can make an array of all the channels and use only one config vi to configure all for output at one time. Use the function DIO Config.vi found in the functions palette at NI Measurements - Data Aquisition - Digital I/O - DIO Config.vi. This will do all channels at once. Just wire an array containing all channel strings (a string array with elements of 0,1,2,3) to the Port List input of the config vi. Wire a numeric 0 for the group number. Right click on the Group Direction input and create a constant. It will create an enum in which you can choose "output". Wire in the device number. No other inputs are needed, leave them unwired. Use the DIO Write function from the same palette, pay attention to the write location input cluster to choose which lines to write to.
If you do not want to group all ports together, just config one channel at a time and be sure to use the task id output from config to go to the correct group write input.
- tbob

Inventor of the WORM Global
0 Kudos
Message 9 of 14
(3,370 Views)
tbob,

Do you think that this will be a little bit more workable? I'm not able to test until Wednesday afternoon.

The actual equipment is presently 20 miles away, but I had a copy of the .vi that I could edit remotely.

Thanks for the pointers!

Cheers!
-darren

Message Edited by DarrenC on 03-15-2005 06:40 PM

0 Kudos
Message 10 of 14
(3,365 Views)