anyone ever have issues with waituntil commands?

[howling60]

I am just wondering...as i seem to run into issues once in a while.

my situation is this... I will have some input, say input #30 that i am waiting on a status change to 1 before my routine progresses. To do this my code looks like this

IF #30<>1 THEN WAITUNTIL #30=1
rest of routine...

Perhaps I am following an odd line of logic, but I would expect that this code should look @ the status of input #30, and if it is not 1... the code should hold in this state, until #30 goes high, and then drop down through to the rest of the code. This does not seem to happen for me in real life however. My experience so far has been that I must put in a sleep command after the if/then, and prior to the waituntil.. otherwise, the code essentially ignores the waituntil, and goes off on it's merry way, leaving behind a wake of destruction.

I had originally written my routines using if/then loops, only to find that the control would hang upon entering the loop. So, that is out..

If anybody could shed some light/insight on this, i would really appreciate it.. as this has been bugging me for a while.
As always, Thanks in Advance!

-nate

[camsoft]

Make yourself a Logfile.Fil file and follow it through. If you still help send it to us with the note you wrote here.

Tech Support
CamSoft Corp.
(951) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

[HuFlungDung]

How long is too long to wait? I suppose that maybe your logic needs something to do while it waits and checks....just a wild guess. WaitUntil MIGHT suspend processing so it might not properly see the input change state.

Inputs can only be 0 or 1, so you could better define the conditions:
:STARTLOOP
IF #30=1 THEN GOTO :CONTINUE
IF #30=0 THEN SLEEP .1
GOTO :STARTLOOP
:CONTINUE

[intrusion]

Modified version of what HuFlung stated. Just a bit quicker to execute

:STARTLOOP
IF #30=1 THEN GOTO :CONTINUE
GOTO :STARTLOOP
:CONTINUE

Note, however the above could be an endless loop if the input never changes state to a value of 1, bad switch ect....

Also try this
IF#30=0THENWAITUNTIL#30=1
Basically remove the <> and replace with =0, however <> should be valid.

The LOGFILE CamSoft suggested would be the best route to figure this out in any case.

[HuFlungDung]

Another question which may be relevant is how long does #30=1 ? Is it only an instant and then its back to zero?

[howling60]

first off, i want to say thanks to everyone for checking this & tossing out some ideas

i have made logfiles to try and figure this out, and far as i remember (it has been a while as my attention has been on other things), the controller looked @ the input, saw the waituntil.. and ignored it, moving on to other logic.

HuFlung: I had tried versions of what you are suggesting, however... that seemed to drop the controller into a nasty little logic loop, from which it could never escape.. caused even more problems. It was actually upon Camsoft's reccomendation that i removed the If/Then loops in *favor* of the waituntil command. I was also thinking that the waituntil might be holding up the system, so that it could not see the input status change, however the control is not hanging, it is just ignoring. Currently i have a sleep of 2 seconds in the routine to help it "see" the change with the waituntil.

Intrusion:
see note above in reference to logic loop
Also try this
IF#30=0THENWAITUNTIL#30=1
Basically remove the <> and replace with =0, however <> should be valid.

been there, tried that.. both with the <> and =0 both options work fine, if the delay between the initial check, and the input status change is short. however, i'm working with a machine that doesn't like to be rushed.. she takes her sweet time, which is where i run into the issues of waituntil being ignored

As for the input being a rapid change: It is actually on a zero speed line for my spindle that i am currently seeing the problem. The spindle is commanded to stop, and then the routine should wait until the zero speed goes high, then an orient is performed (camsoft only gets a spindle ramping & zero speed for reference, no encoder feedback). This time around, the problem caused me to blow out the orient plunger, as the spindle was still turning 1k when the plunger fired .

in any case.. i will go and monkey around with stuff, and see what i can see. I saw a similar issue posted a while ago, regarding a waituntil stop command, where the solution seemed to be a series of waituntil stop: waituntil stop heck.. i'll put in 10 of them if it means not blowing out any more parts.

I would like to know why this seems to be an issue however. Camsoft, does the waituntil command "hang" the system in any way, that might cause it to possibly do funky things? I know it is stated that the waitauxio command will ignore all other io changes...

anywho, thanks everyone!

-nate

[HuFlungDung]

Are other motors possibly in motion, or nearly finished their motion when this logic is being applied? I'm just wondering if such were to happen, that an incomplete movement may hang your system, and it comes out looking like the error is at this input?

So this zero speed signal, is it an actual switch, or some kind of hi/lo state, where lo does not quite equal zero? If the loop hangs indefinitely when properly written, it sounds as though there is not a clear indication of #30 going to zero. Try wiring a simple toggle switch into that input circuit, use the WAITUNTIL or equivalent loop and see if it works more reliably when the circuit actually is broken. If it works consistently, you might need a small relay operated by the #30 and then use the relay contacts as your actual input line.

[howling60]

it's a high/lo output on the spindle drive, which then throws an opto-relay. So i'm pretty sure it knows if/when it's at 1 and 0.. i'll run it again once my orient plunger is repaired, with a logfile, as i cna't power up the machine w/out my hydros right now

the issue however isn't with the system hanging, it's with the system seeming to ignore the waituntil command, the exact opposite of hanging.. just running through instead. I dunno.. it's got me stumped.. perhaps another vacation from the machine is in order so i can come back with a clear head again

-nate

[murphy625]

Nate,

I had a problem like yours. I forgot exactly what the problem was but it had to do with an input and my program code not executing correctly because of it. I think mine was a looping problem...
Anyhow, try breaking it down to the absolute basics and running it manually. Run a couple wires to your desk and keyboard from that switch that is supposed to trigger the waituntil command. Unload your entire setup and create a brand new interface / codes with nothing but that input and start testing it.
There was one time I found that the code I wrote was fine but my switch was wired NC instead of NO.. It was a simple fix..

I use plenty of WaitUntil commands and they seem to work perfectly in my application.

My point is this:
Get rid of all other things physically and programmatically so that you are working with nothing but a switch, a piece of code, and a few wires. One you do this, finding the problem should be a much easier task. The fact that you say the program seems to ignore the Waituntil tells me that there is something "physical" in nature that is going on.. I could be wrong.. I'm a newbie myself but what I have learned is that when camsoft says it should work, it should work.. If it doesn't, its usually my own fault with a crossed wire, a bad switch, bad optical relay, or some other stupid thing that makes me feel like an idiot when I find it...
The one trouble shooting procedure I have learned to follow is to remove all other accessories, code, switches, I/O's, etc etc and do my testing with only the most basic requirements. It takes a bit of effort to unload my CBK file and create a new one, disconnect other wires from the IO boards, etc,, but it has proved to save me time in the long run when nothing else seems to work.
The old famous quote applies:
"When you have eliminated all other possibilities, what is left must be the answer"

Hope this helps.
Murphy

[camsoft]

Nate,

After reading what you just wrote, we believe we got this figured out. We haven't seen the Logfile.fil yet to confirm this but it does seem obvious.

First we can answer and explain a few of the known items that were brought up.

(1) The logic is Boolean. The values will either be 0 or 1.
Using the statement <> 1 or =0 is the same for I/O


(2) When one command is more appropriate than another depends on many strategies, but in general use.
WAITUNTIL is a tight method for focusing on a certain event
WAITAUXIO is a very tight method for fast reaction to I/O on auxiliary I/O boards
IF THEN is best for freeing up more computer resources to process other logic files running in the background.

WAITUNTIL is the best method in this case.


(3) No need for multiple WAITUNTIL commands in a row to check for the same I/O state. Unless you where waiting to hit the switch (1) and then wait to come off the switch (0).

(4) No need to use IF THEN for WAITUNTIL
Example: IF #30<>1 THEN WAITUNTIL #30=1
The WAITUNTIL command all by itself without IF THEN will work.
If #30<>1 then WAITUNTIL would wait until is did anyways.
If #30 did equal 1 then WAITUNTIL will pass on by anyways.


(5) The logic must be passing by the whole line, NOT ignoring WAITUNTIL.
IF #30<>1 THEN WAITUNTIL #30=1
It's not that the IF THEN is true and then it ignores the WAITUNTIL. It is passing by the IF THEN because at that time it is a false statement and doesn't ever execute the WAITUNTIL

(6) Here's what is most likely happening.
#30 must be a switch you're waiting on after doing some logic above this in the file. The physical switches on the machine need time to engage or disengage but the logic for checking I/O runs at compiled speeds. A slight delay is needed to allow the physical switch or pin to engage. As you mentioned the machine is heavy and slow as compared to the speed at which the computer can process and check on switch a moment is required before it checks.

Whatever event before this that executes the next step which in this case is #30=1 has flown by the logic by the time it gets there. What we are saying is that I/O #30 is already 1 at this point.

Here is the cleanest way to write this:

SLEEP 2
WAITUNTIL #30=1


Tech Support
CamSoft Corp.
(951) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

[howling60]

camsoft:
hhmm I do see what you are saying, and i agree with the diagnosis that I am indeed dealing with a large & slow machine, which cannot physically react nearly as fast as the software can. At the same time however (and once i can power the machine up again i will test this) input #30, is on my zero speed for the spindle. This consistantly, and reliably only goes high when the spindle motor is essentially stopped (below 3 rpm). When i am decelling from a 1200 rpm spindle rate, to a full stop. I am looking at a time span on the order of 4-5 seconds before that line can have a chance of being driven high, signifying that the spindle has stopped turning.

If input #30 had gone high, and the code blew by it, i would be happy as a clam, as it would signify that the spindle was no longer turning, but i can't see how that input would have gone high prematurely.

I will check back in after i have had a chance to make up another testing routine/logfile for this, but it'll be a few days as we must make the new orient plunger before i can power anything up again.

As usual, thanks for all the ideas/suggestions/help everyone, it is most appreciated.

-nate

[keithorr]

Is your input device stable? I was getting false "high" on my input until I started using an isolated power supply for the input common.