02-24-2009 11:45 AM
Hey,
I am trying to run a program which controls a remote power supply. The way the power supply (BK Precision 1786B) is controlled is by writing a 26 byte hex array with specific addresses for each command (20= remote control setting, 21= output of voltage status, 23=set voltage, 24=set current, etc.) The way I am communicating to the power supply is by sending the code through the basic serial read and write VI. It has worked phenomially. I would like my program to turn on the remote control, turn on the output status, start ramping up the voltage at a fixed rate, and then when the desired voltage is hit, the stop button is pressed and the last command to set the voltage back to zero and output status off before the whole program ends. The most important thing I am asking for is the ability to set the voltage to zero directly after I press stop. I am controlling a peltier chip and what is happening is that when I restart the computer, the chip will be a surge of a high voltage before resetting to zero because of the code.
ANy thoughts?
Thanks,
Katie
Solved! Go to Solution.
02-24-2009 12:12 PM
You did not include the subVIs but I don't understand what the issue is. You've already got a couple sequence frames that run after the stop button is pressed. Since you have them, why isn't one of the frames setting the voltage?
p.s. If you used correct dataflow and design of the subVIs, the sequence structure is completely unncessary. Add error in/error out clusters to the subVI as well as VISA Resource Out, and you control the execution flow by wires.
02-24-2009 12:14 PM
Look at the state machine architecture. You would have a different state for each part of the process.
I don't have your subVI's, so I can't see what is in them. It seems awkward to run the serial parameters to each an every instance of that subVI. I would recommend modifying it or wrapping them into a subVI so that it stores the serial parameters. Look at Ben's Action Engine Nugget.
02-24-2009 01:25 PM
Here are the subVI's. The hex is just a simple subVI which accepts the commands and puts them into the 26 byte array and the other is just the basic serial read and write with the redundant number array to hex string with checksum.
I have not ventured into using error ins and error outs or the error case structure which is seen on the community nugget. I am not finding the error loop on my function pallette.
02-24-2009 01:39 PM
02-24-2009 01:44 PM
I hope the stop button you are pressing is the Boolean stop on the front panel and not the abort (stop sign) on the tool bar. Never use the abort button. If you use the Boolean stop, the while loop will stop and the frames will execute.
I also hope you are not using the run continuous button. That is to be used only for certain debug conditions.
02-24-2009 02:00 PM
02-26-2009 03:25 PM
Hey Raven Fan,
Thank you for the link to the action engine discussion. I started out trying the enum and was not quite getting it to work so I started messing around with the event case so that it would be a bit cleaner. Would you mind looking at it and seeing if it is the most efficient way to set this problem up. My other question is how to initiate and keep the slow ramp up in voltage, which occurs in the last event case. I am not sure if that should be a separate VI or if I could keep it contained in this one. Thanks!
-Katie
02-26-2009 08:42 PM
The subVI's you attached were named differently from the ones you actually used in you main VI. I relinked them into the code so I could see what they looked like. The colors you used on those subVI icons were horrible. Blue text on a black background was completely unreadable.
One problem you have is that you are not using a state machine architecture. Your last event case will fire only when the value of the numeric control changes. Then the next iteration will start and the event structure will wait again for something else to happen. There is nothing to advance the ramp to the next step.
An event structure is good to use for handling front panel events such as button presses. But embedded as part of your control loop means the control loop only ever runs if some event happens. There is nothing to allow the automatic ramp up to occur.
Go to File/ New..... and look for Producer/Consumer Design pattern using Events. Also, look at Standard State Machine architecutre. What you will need its a combination of both. You need the Event structure in its own while loop. It will pass commands onto the other loop that would be your state machine.
You have lots of coercion dots in your program where you use integer constants in places where the functions or VI's are expecting doubles. Change the representation of many of those constants and the coercion dots will go away. At best, they are a nuisance and extra data copies as LabVIEW converts the databytes. At worst, unexpected conversions could change the way the code operates.
02-27-2009 01:13 PM
Hey Ravens Fan,
Thank you for your help. I understand what combining the produce/consumer design pattern and the state action VIs gets you. I am having trouble understanding how to keep the state action V (the ramp) going. It seems that when you press the queue button, which I have replaced with the start test button, that it executes the loop only once and then stops. I am sorry if I am missing something very obvious but I was wondering if you could provide some insight. I have changed the black/blue on the VI so it is more legible.
Thanks,
Katie