Triggering boolean modbus variables

[brade034]

Hello, I need some help with switching a boolean variable on and off really fast.

What I want to do is have a switch activate a solenoid for a split second. The switch will stay on until the experiment is over, which will be a few seconds later. It should reset after that.

As it sits now, the switch is wired directly to the solenoid and controls it directly. The problem is I only want the solenoid activated for a short time in comparison to how long the switch will be on. Hopefully that makes sence. Thanks for any help you can give me!

[RavensFan]

Conflicting requirements.

You say you want it to be on for a split second, then stay on until the exeriment is over a few seconds later.  Is it a "split second" or several seconds?  How long is a "split second" in terms of time such as milliseconds or microseconds?

You said you are using modbus?  What kind of device is this?  If you are talking milliseconds, I don't know if you can reliably turn on and off something using serial or TCP/IP communication of a modbus device in that short of a period of time.  You may want to build a circuit that has some sort of built-in time that only activates for a short time upon detection of the switch going on.

[brade034]

Sorry, Im doing a terrible job at explaining. Ok, so whats happening is a furnace is lowered over a hanging fuel droplet. An igniter, attached to a pnumatic actuator, then comes up from below the drop to provide the required activation heat to start the droplet burning. The igniter should only be in it's top position for roughly 25 ms then immediately lowered. After the droplet burns, the furnace is raised. The whole process only takes a few seconds.

Its an Advantech TCP daq. I had some suspision that it might not be as quick as we want, but I was willing to try it in labview if there's an easy way to program it. Hence the question.

[RavensFan]

You can use an event structure if you are using an onscreen switch.

If it is a hardware switch, you can use DAQmx to detect the state of a digital input.

When you detect the switch goes from off to on (there are some point by point subVI's that can detect the transition), go through a quick sequence where you activate the solenoid, wait 25 msec, then deactivate the solenoid.  Then test it out to see if the communication is quick enough and whether windows can reliably control the 25 millisecond wait.

[brade034]

Ok, so I tried wiring the switch to a case function. Inside is a point by point square wave generator going into a greater than going into the solenoid actuator. It works, but the solenoid stays on. Shouldnt the greater than return false when the square wave is done? Do you think this will work? The 25 ms isnt really important, just as long as its quick.

[RavensFan]

Show your code.  I don't remember saying anything about wiring the switch to a case function.

[brade034]

Ok, dont laugh. Im a labview beginner.

[RavensFan]

No idea why you have 3 while loops and 2 stop buttons.  And the outer while loop is infinite.

No idea why you read a boolean shared variable, if it is true, it executes the true case, but controls a while loop also.  That 2nd while loop in is automatically going to stop after one iteration because the boolean value coming into the OR before the stop terminal is true.

No idea why you are using square wave pt by pt.

I'm assuming one shared variable is the input and the other is the output you want to control.

Attached is a VI demonstrating how to do the triggering and 25 millisecond output.  I stripped out everything else because the while loops are a mess, and the other code isn't significant to your question.  You can look at this and figure out how to work your file saving code back in.

[brade034]

The outer while loop is there to continuously check the boolean condition. Once it's true, the rest of the code starts. I dont know if thats the "right way" to do it, but it works for us.

The boolean controls the while loop so it stops collecting data if false. It works the way it was intended and doesnt run for only one iteration. I dont know why though.

The idea behind the square wave was to have it trigger the solenoid. If the wave had a 25 ms duration, it could be run through a greater than that would then trigger the boolean. It was the best I could come up with. Again, Im a total labview noob and dont really know the proper way of doing things.

Ok, that looks simple enough. I'll work on getting the rest integrated. Thanks so much for your help and for putting up with my subpar labview skills!

[RavensFan]

---

@brade034 wrote:

The outer while loop is there to continuously check the boolean condition. Once it's true, the rest of the code starts. I dont know if thats the "right way" to do it, but it works for us.

---

How do you stop the VI?  You can't.  You are forced to hit the Abort button because the outer while loop as a false wired to the stop terminal.  The abort button is intended for program debugging.  A way to stop the program if it gets stuck.  It shouldn't be used to stop a normal VI.  You have no control over where in the program is in the code at the time you abort it.  It could leave your outputs in an undesired state.

---

@brade034 wrote:

The boolean controls the while loop so it stops collecting data if false. It works the way it was intended and doesnt run for only one iteration. I dont know why though.

---

Impossible!  Your outer while loop runs and will run forever reading shared variable  000048.  When the shared variable is true, then the true case runs and the 2nd level while loop starts.  The value on the wire is true and will remain true as long as that while loop runs.  That true value when ORed with the stop button means that 2nd while loop will stop on that iteration.  Eventually when your innermost while loop finally stops with your unmarked boolean control, then the case will end and the outermost while loop will iterate again.  If your shared variable is still true it will start all over again.  Maybe that is why you think it is working the way you want.  You can safely eliminate the 2nd level while loop, the OR, and the inner stop button and you will find your VI will behave exactly the same.

(By the way, it is not a good user interface to have multiple stop buttons.  It will confuse a user if they hit a stop button and the program doesn't seem to stop like they thought it would.  They are fored to learn to the magic combination of what buttons to hit in what order in order for things to stop.)