Another insane request

[christinandavid]

Hi all,

Have been fiddling with the timer/clock macros to monitor efficiency (lack of).

I know there are system parameters that store cycle time/cutting time but as far as I am aware these cannot be read/manipulated at the control via macro programming - so I have (eventually) got to grips with custom macros #3001-#3002, #3011-#3012 and its spewing out the info I want.

Wasn't until I'd got it sorted that I realised an issue - an M00 or an M01 halts the program, but timer #3002 is still ticking over as the green button light (STL) remains on. This is not what I want, as the machine may stop over lunch time, for instance, adding more cycle time when in fact nothing is happening.

Is there any way to alter the behaviour of the control via system parameters or maybe a macro pgm at an M0/M1 to get around this? Some sort of 'one shot single block' command or 'programmable feed hold' to cut the cycle signal?


Cheers,

DP

[samu]

Strange that the green light remains on when M0 or M01 or feed hold is commanded!

Suppose that the following macro is called By M0:

#1=#3002
M0
#3002=#1
M99

After the pause, #3002 is set to it's value before the pause. It should work

[christinandavid]

Yeah the big green aircraft beacon at the top of the pole turns off, but #3002 isn't watching that, its watching the cycle start button, which is only switched off when cycle 'state' is altered by reset, single block or feed hold. This is also the case with the system parameter cycle timer, yes it seems odd that M0/M1 doesn't stop these timers...

I was thinking about a 'non-physical' way to get the same effect as 'feed hold'/single block mode -
- but the more I think about it, the more the assigned macro to measure the pause seems like the better option.

I will try a slightly different format, the macro will simply store the timer value and immediately return to main program. This will mean that the main program will always be displayed and guard against reset before time capture.

Our 'running job' program format always calls a standard macro that sets up our pallet/offsets etc at every restart sequence number, so I'll get this one to reset the timer to the saved value.

Doing it this way should also help stop the actual cycle times being polluted by any manual operation or MDI commands (I can't remember ever using M0/M1 in MDI).

How will the M1 behave when I assign a macro to it ie will the macro only be called if opt stop is active?

If opt stop IS active will the macro be called before or after the stop? Obviously if the macro isn't called first the time will not be captured should a reset occur...

Cheers,

DP

[sinha_nsit]

When you redefine M1, it will have nothing to do with optional stop status. The assigned macro would always be called. Once inside the macro, the M1 code used there would become a normal M-code with usual behavior.

[christinandavid]

So if optional stop is active the control should pause once it returns to main program? Or have I been thwarted again? There will be no M1 in the called macro.

DP

[christinandavid]

I am clutching at straws here aren't I? I'm going to need to pause within the M1 macro, or redefine a completely new M-code at the end of each process and make it part of our standard program format....

[sinha_nsit]

You need to use M1 inside the macro called by M1. Effectively, it would be the original M1 with some added feature.
The same thing, however, cannot be done with M0. When you wish to call a macro/subprogram by an M-code, the associated M-code number has to lie between 1 and 99,999,999.
So, do not use M0 if it does not stop timer.

[christinandavid]

Cheers for the advice - will probably go for an extra M-code at the end of each process - our current format looks like this: -

N5 (Milly Vanilly);
G65 <PARAMETERS>;
G123 D1 R0; This is the auto setup macro that performs pallet changes and B-axis/offset rotations - I will add to this to time those events and start timing the tool call sequence.
T#101 M6 (Fork); <--------I will add a bit to tool call to finish timing the tool call sequence and start timing axis motions.
/T#102 (Spoon);
G0 G90 X Y blah blah blah;
G91 G28 Z0 M9;
M5;
<---------------------------Will add my new M-code here to update time for that tool and stop timing
M1/M0;
;
etc

A seperate new M-code as part of our standard program format will work out best for me as it will keep the cycle timing seperate from any manual intervention - of course, if the program is stopped/restarted mid-cycle it may all go tits up - unless I can get macro to detect an unfinished/rerun process and reset time accordingly

The general idea is to seperate the component pieces of a proven cycle on this machine to gauge its performance more accurately against the smaller, faster machines, this will also give us better estimates when jobs proven on another machine come onto this one, I hope...

If only I could decide on a number for my M-code...

DP

[stevo1]

Originally Posted by christinandavid If only I could decide on a number for my M-code...

I've always liked using M123 for these types of situations because it sticks out.

Stevo

[christinandavid]

Well I already use G123 for my setup macro, cause it makes things easy as 123 - I need something else - maybe the number of the beast...

[stevo1]

Oh boy don’t get the demons in the machines all stirred up. They will mess with your timers until you go crazy

Stevo