Need help with Ladder edit 16iMB - looking to use user macro output.

[dandrummerman21]

Someone trashed a tool today because a hard switch for coolant auto was not turned on.

I would like to edit the ladder (i have LADDER III) and have already done so. I've even tried what I thought might work but hit a snag, as it doesn't do what I want it to. I'm sure it's relatively simple.


The status of R291.3 turns to 1 when the auto switch is on. I want to write a quick subprogram (called with m-code) that checks if the switch is on.

I figured I would choose #1115 as a user macro output for my check program.


So what I thought I wanted was:

---|\|------------0---
R291.3 F55.7(uo015)


However, fladder doesn't let me use f55.7, says cannot be written to. So I tried G55.7(ui015)


---|\|----------------0---
R291.3 G55.7(UI015)



This ladder compiled. And I loaded it into the machine. But doesn't seem to change any user macro variable at all (#1000-1015 / #1100-1115) when I toggle the switch.


What am I getting wrong here? And does anyone have a suggestion how I should write it?

 

[dandrummerman21]

Also worth noting that when the R291.3 changes state, the G55.7 does not.

There are other user macro inputs being set in the ladder, they go up thru G55.5. G55.7 was unused.

 

[Milling man]

The second version of the program looks quite right. The CNC PMC variables are G54.0-G57.7 (macro variables #1000-1031). You said G55.5 is being used. Does it work correctly?

 

[dandrummerman21]

The second version of the program looks quite right. The CNC PMC variables are G54.0-G57.7 (macro variables #1000-1031). You said G55.5 is being used. Does it work correctly?

Yes it does. It has to do with the pallet change. G55.4 for pallet 1, G55.5 for pallet 2. When the signal for the pallet change lights up, the user macro also lights up.

 

[Milling man]

Are you sure that G55.7 is not used anywhere else? I don't even know what else could be causing this...
Are there free variables smaller than Г55.4? Maybe try others? The CNC is already aged, maybe the G55.7 does not work due to a broken memory cell or something like that.

 

[dandrummerman21]

G54.2 and .3 are not being used
G55.2, .3, .6, and .7 are not being used by the original ladder.

I'll try G54.2

 

[dandrummerman21]

Didn't work?? G54.2 stays unlit.





Is there something wrong with how I did it? Does the bit have to be "enabled" in any way in FLadder? It was already defined, but I checked and double checked and it is not in use anywhere in the ladder. I checked the crossref page too, and searched the ladder in the machine. I hit the compile button and there were no errors. The machine runs with the ladder as-is.

I sent the ladder to the machine using the startup menu thing (right 2 soft keys under the screen) called "System Loading" or something like that.

 

[Ox]

I can't help you, but I sure feel your pain!
My Siemens mills are like that.
They boot up "off" even if it reads an M8.
Piss me off!

That cost me $100 each time...


--------------------

Think Snow Eh!
Ox

 

[sinha]

Is it possible to drive G55.7 (which defines #1015) directly by the associated X address?

 

[dandrummerman21]

Is it possible to drive G55.7 (which defines #1015) directly by the associated X address?

In short, no.

The wire from the switch goes into a pcb that outputs both the handle x10 and coolant auto switches into x36.4. I don't really understand how that works, but if you look at x36.4, it strobes on and off rapidly depending on what switches are on.

The status of R291 (the whole byte) is output by a SUB 8 command depending on the inputs of 3 different x bits.


Confusing way to do it but I guess they saved on some i/o?

Pictures attached.

 

[Milling man]

Didn't work?? G54.2 stays unlit.

Damn, I'm out of ideas.... No, I have a couple of ideas though:
1. Try to install some X instead of R291.3, any one that will definitely be turned on. Just for checking.
2. Try replacing R291.3 with Rххх, which is 100% enabled - there should be a variable like "Servo ON", or something like that. I have a slight suspicion that R291.3 is displayed as 1, but in fact this is not entirely true. This happens with Fanuc More often this happens with variables like R9000, but you never know how this thing works.
Try to see its status through the "TRAYS" function.
3. Try to temporarily change the line from G55.4 - replace R41.5 with R291.3 in it. Look at the result and immediately change it back.

 

[dandrummerman21]

Okay. So I figured it out. Well, i didn't figure it out actually. But I did get it to work. It still exhibits the same strange behavior but it works how I want it to. Maybe someone will know why. This is what I did.


I looked into the trace function, and traced R291.3 and G54.2. G54.2 stayed LOW when R291.3 toggled on and off.


The next thing I did was try ---| |----- instead of ----|\|-----. That did not work.

I moved the rung to below where R291 is being set. That did nothing.



Then I got to thinking- What if I try to set another R with R291.3. And then I used that R to set G54.2. So I picked R330.0

Note that in the following pictures, it does the same thing; R330.0 does NOT light up when R291.3 is on. But on the second line, G54.2 lights up as if it were! I also ran a TRACE on all 3 bits. Very curious that R330.0 also stays low there too!






Now, while that's f'n strange, the macro DOES work now. #1002=1 when the coolant auto hard switch is on. I have made a subprogram to have it check before every tool starts cutting in this production program.

 

[Milling man]

Well, it works - and it's great!

 

[sinha]

Note that in the following pictures, it does the same thing; R330.0 does NOT light up when R291.3 is on. But on the second line, G54.2 lights up as if it were! I also ran a TRACE on all 3 bits. Very curious that R330.0 also stays low there too!

If ever you come to know about the reason, please do share with us.
Can there be a timing issue?
How about using R291.3 only, in two consecutive rungs?