[nazdackster]

I added an input (flow switch) to an 18i control. I added a rung in the ladder like:

----| |----------------------------------(   )-------
   X0021.1                              G54.4 #1004

I'm using it to detect flow after I turn coolant on. It works fine in the main program O0248, but when I call a different sub M98P0301, where I also want to turn on and then look for the coolant flow, it does not work (so it activates my alarm). I can see it working in the ladder, the flow is on, and I wait long enough before I look, but [#1004 NE 1] is true, so it alarms.

I thought system variables (inputs) should be visible across all macros / subs.

For now, I simply disabled the feature I wanted in O0301 (a warm-up, slow grind in the morning if the delay since last grind is more than 100 minutes)

Seems very odd that it works fine in the main, but not the sub... Any ideas? THANKS !!!

[txcncman]

I think variables have to passed off to subs with a G65 custom call.

[sinha_nsit]

I thought system variables (inputs) should be visible across all macros / subs.

I also believed this till I saw your post. Yes, this is pretty odd.

However, I still believe that these must be available in subs, even if not in macros, since a sub uses the same set of variables; it is like extension of the calling program.

It is possible to pass on the status of system variables inside a macro/sub through local/common variables.

Incidently, though may not be relevant for this case, one has to be careful while using EQ or NE because of round off errors.
For example, 1 NE 1.0000001

[stevo1]

System variables can be read thru a macro or sub call program. It is quite odd that it is not working for you. They are what they are and nothing should change them coming into the macro or sub.

Here is something to try to see if it maybe has not changed yet or it is being set to a different value for whatever reason as Sinha said.

#1=#1004
M0
[#1004 NE 1]

When the machine stops at M0 look to see what #1 is set to make sure it is changing it when it should. Now if something goofy is going on like the floating point math then you could try using IF[ROUND[#1004]NE1] although I doubt this is the problem.

Stevo

[nazdackster]

Thanks for the help... I found this message on page 894 of manual B-63523EN-1/03 (found Here)

When a system variable listed in the table below is used in a macro
program, and the macro program needs to be executed after the block
immediately preceding the macro program is executed, an M code
(parameter No. 3411 to No. 3432) for suppressing buffering or G53 must
be inserted immediately before the macro

I haven't tested this, but based on looking up those parameters and other areas it sounds like I could put an M01 just before executing the IF, and I think this would prevent it from looking ahead too far... It almost sounds like it might be looking at the flow switch before I turn the valve on. I don't have anything in there that would inhibit look-ahead. Does this effect sound possible to you folks? I am definitely calling it as a sub, not a macro.

I'll let you know if it works, but would be interested to hear if look ahead can cause this timing issue.

[stevo1]

Oh yes most defiently it will cause this problem. The only reason I did not suggest it is because I took what you said in your first post "and I wait long enough before I look" to be you had a dwell or that the IF statement was many lines after you turned on the coolant.

I have had this problem many times because the macros I write execute faster then the system variable can register the proper setting. There are a few things that you can do. You can put a dwell before the IF statement G4X(). You could also put a handful of EOB before the IF statement. Also if your machine supports turning off the look ahead via G-code you can turn if off before the coolant on and then turn it back on after the IF statement.

If you try my suggestion in my first post you will know if the look ahead is grabbing the wrong value for #1004 before the IF statement.

Stevo

[nazdackster]

Thanks Stevo...

I guess that explains why it works in the regular program but not the one that gets called after a long delay.

In a normal grind, I turn on the coolant, then call this O0301 sub (which usually does not grind, only adjusts offsets after delays), then I call another that checks wheel diameter and adjusts dress amount based on the amount left (it doesn't need much when big, but needs more dress later), then I call another that does my gauge compensation, which is about another 40 lines of code, then I look for the flow switch...

In the O0301 sub, if it was more than 100 minutes since the last grind, I just turned the coolant on, waited G04P250, checked the switch, then called the grind macro. Fault. So I waited G04x2.0, and that wasn't enough either. So I think it had already looked way past the flow switch check, it wasn't about the amount of time, the controller had already blown past that line of code and moved on. The solenoid wasn't even turned on yet.

This sounds like it could be a big problem...

What I read was that the M01 (optional stop) will make sure nothing is executed past that line until it should be, in case a stop is called for.

Look-ahead sounds kind of risky, but I guess I just don't understand it well enough.

Do you think M01 after a timer and ahead of the float switch check will work?


Thanks again.

[MysticMonkey]

Using Parameters 3411 -> 3420 you can use any m-code to suppress the NC from processing all arithmetic expressions and conditional branches. yes M01 would be a good choice
alternatively parameters 3421 -> 3432 to set a range of m-codes

[sinha_nsit]

Another example of look ahead problem:
Let us say the requirement is to keep an output ON for 10 seconds, and then execute further.
#1100 = 1;
G04 X10;
#1100 = 0;
It would not work!
#1100 would remain ON only for a fraction of a second, even though there would be a dwell of 10 seconds before executing the next NC-statement.

[nazdackster]

#1100 = 1;
G04 X10;
#1100 = 0;
It would not work!

So if I understand this correctly, a good countermeasure would be:

#1100 = 1;
M01 (optional stop to disable look-ahead);
G04 X10;
#1100 = 0;

I'll try that technique today. Thanks again everyone!

[sinha_nsit]

M01 should come after G04.
A couple of EOBs after G04 would also work.
Just a single EOB in a block is considered an NC-statement (blank NC-statement).
For NC-statements, generally look-ahead is just one or two blocks on common Fanucs. But a large number of consecutive macro-statements may get executed.

[fordav11]

the look-ahead buffer is 3 blocks as stated in Fanuc manuals, from 6M/6T to later 16/18/21 controls

[sinha_nsit]

That is correct.
Three blocks in radius compensation mode, if there are two consecutive non-movement codes in the plane of compensation.

[fordav11]

AFAIK it's 3 blocks period, regardless of being in a compensation mode or not.
unless you can find something in a Fanuc manual that states otherwise?

[dpuch]

Look ahead is great for machine movements, ok for most linear macro programming but cause grief when mixing macros with actions that use them within the look ahead window. As stated the default is 3 lines, and I think 15 or more lines with options. A dedicated m code for look ahead suppression is a great way to solve these issues. A single command on one line and no program delays needed.

Many controls (color screens at least) display the look ahead buffer as different colored lines.

[nazdackster]

M01 should come after G04.
A couple of EOBs after G04 would also work.

M01 after G04 took care of it... THANK YOU TO ALL WHO RESPONDED !!!

I noticed on my Robodrills (31i) that look ahead is colored in blue... On that control, it seems to be a lot higher than 3 blocks, maybe up to 6 when my programs are running (YMMV).