Matsuura horizontal pallet change help

I have a Matsuura h-Plus 300 with a 16i controller.

My machine is a 2 pallet machine, is there a way I can tell the machine to load pallet A into the machine or Pallet B?

What I would like to do is:

%
O12345
(Load pallet A) - If pallet a is in machine, the control should ignore and advance to the next line.
Goo G90 .....

body of program

....

(Load pallet B) - To allow pallet A parts to be changed.
M30
%

I can change pallets using M62 but this does not allow me to choose which pallet nor does it poll the ready switch at the load station.

The machine has a M61 PALLET CHANGE (schedule operation), but this forces me to use a different main program that polls the scheduler, then the control automatically switches to the program I want to run before continuing.

I just want to have a single program but still have a way to verify that I am running the correct pallet. I hope that makes sense.

Thanks!

haastec said:

I have a Matsuura h-Plus 300 with a 16i controller.

My machine is a 2 pallet machine, is there a way I can tell the machine to load pallet A into the machine or Pallet B?

What I would like to do is:

%
O12345
(Load pallet A) - If pallet a is in machine, the control should ignore and advance to the next line.
Goo G90 .....

body of program

....

(Load pallet B) - To allow pallet A parts to be changed.
M30
%

I can change pallets using M62 but this does not allow me to choose which pallet nor does it poll the ready switch at the load station.

The machine has a M61 PALLET CHANGE (schedule operation), but this forces me to use a different main program that polls the scheduler, then the control automatically switches to the program I want to run before continuing.

I just want to have a single program but still have a way to verify that I am running the correct pallet. I hope that makes sense.

Thanks!

Click to expand...

Hello haastec,
Unless there is a proximity switch to identify the current pallet and the I/O System Variable to read the state of the prox, you can achieve what you want with a couple of simple Macro Programs, wherein the current pallet is stored in a Common, Nonvolatile Variable. Example follows:

O9003(AUTO*PALLET*M61)
(PROGRAM CALL M61)
M11
IF[#500EQ1]GOTO5555
IF[#520EQ61]GOTO1
G91G28X0Y0Z0B0
G30X0.0Z0
M60
#520=61
G90
N1M99
N5555
#3000=1(PALLET CHANGER DISABLED)


O9004(AUTO*PALLET*M62)
(PROGRAM CALL M62)
M11
IF[#500EQ1]GOTO5555
IF[#520EQ62]GOTO1
G91G28X0Y0Z0B0M09
G30X0.0Z0.0
M60
#520=62
G90
N1M99
N5555
#3000=1(PALLET CHANGER DISABLED)

The above examples were Macros I wrote for a two pallet horizontal that sometimes had an After Market indexer mounted on a pallet for a particular job. When the indexer was mounted, it and the workpiece couldn't fit through the pallet changer door; therefore, there was another Macro Program that set #500 to 1 to disable pallet changing when the Indexer was in use.

Regards,

Bill

Hi Bill,
We have 2 Matsuura MAM-600HF-PC12 that have been fitted to a 27 (25+2) pallet stocker system. We had some problems with the optical sensors on the vehical that I have since changed. After getting things reset and the vehical working from it’s own control, I’m having problems with the automated pallet call from either M/C. Right now the machine just sits at the M60 line with no alarms on either control. Let me know if you would like me to post the pallet change program.
Thanks for your help,
Josh

IMS2016 said:

Hi Bill,
We have 2 Matsuura MAM-600HF-PC12 that have been fitted to a 27 (25+2) pallet stocker system. We had some problems with the optical sensors on the vehical that I have since changed. After getting things reset and the vehical working from it’s own control, I’m having problems with the automated pallet call from either M/C. Right now the machine just sits at the M60 line with no alarms on either control. Let me know if you would like me to post the pallet change program.
Thanks for your help,
Josh

Click to expand...

Hello Josh,
Yes, Post the program. Typically, M60 is a Pallet Change with no reference to which pallet is to be changed into position; see the two Macro Programs posted in my earlier Post. M Codes within a Macro program called by an G,M,T codes are treated as normal M Codes. Accordingly, I assume that the M60 you refer to is just that, a Pallet Change command.

What control does the machine have?

I suspect it will be an issue with the sequence of proximity switches, or PLC parameters relating to pallet change. Perhaps the program you Post will shed a little light.

I had a call from a customer only a few days ago; went to do a pallet change and things stopped half way through and from that point, only the Y axis could be moved. It turned out to be the proximity switch on the door between the machine proper and the pallet pool. No alarm.

Regards,

Bill

Thanks Bill,
Here is our current program.

O9061 (AUTOMATED PALLET CHANGE);
#3003 =1;
#1 =#4003;
#2 =#4001;
M09;
M16;
G91 G28 Z0;
G91 G30 X0 P2;
M22;
G28 B0;
M21;
M60; <—- THIS IS WHERE THE MACHINE “HANGS” WITH NO ALARMS ON EITHER CONTROL.
M160;
G91 G30 Z0 P2 M162;
M163;
G91 G28 Z0;
M164;
G#1 G#2;
#3003 =0;
M99;

Thanks again,
Josh

Hello Josh,
If the Macro Program O9061 is being called with a Custom M or G Code, I take it that the control is not Fanuc. What control?

The following Blocks will be positioning the specified axes for the Pallet Change. Its fairly normal with a horizontal machine for the Y axes to be allowed to be in any position for a Pallet Change.

G91 G28 Z0
G91 G30 X0 P2
and
G28 B0

You should have a list of the M codes for your machine and their purpose. What is the function of the following M Codes?
M16, M21 and M22


Regards,

Bill

The control is an i80
M16 is coolant flood off or chip wash off
M21 is pallet unclamp
M22 is pallet clamp

IMS2016 said:

The control is an i80
M16 is coolant flood off or chip wash off
M21 is pallet unclamp
M22 is pallet clamp

Click to expand...

Hello Josh,
OK. The M21 and M22 would be to facilitate the index of the 4th axis to Machine Coordinate Zero.

If you have a hard copy of the PLC Interface program, I would look to the pages that deal with the Pallet Change and find the Input address of proximity switches that are involved; they will be X addresses. There will be a running copy of the PLC program view-able at the control, but following the logic from page to page using a hard copy is easier than doing so at the control. You will be able to confirm the state of the Inputs in the Ladder program at the machine, or on the Diagnostic Parameters pages, also at the machine.

Regards,

Bill

Just me thinking here but if your control could see which pallet is loaded, I would expect that to be a displayed value somewhere in the control. If not, I doubt it knows.

Work arounds. Macro or simple block delete. If you don't use block delete otherwise, this would be very simple.

Tell button cruncher to look for the right pallet in machine and hit block delete when needed.

Program start
O1234
/M62;
make chips here.

Now the macros become harder for YOU but better if you have dumb operators as you can simply ask "uh, the program wants to start with pallet A, so is that like in the machine like now man?"

After not being able to sleep last night, I did some thinking and asked why would the machine do a pallet change from A to B fine, but not when it's trying to use the scheduling from the robot. When I came in this morning I did some wire tracing and found a box mounted on the fence of the pallet stacker. (I started at this company doing maintenance about a week ago.) So in the box was some more PLC I/O cards and some connectors. I reseated all connectors and tried an automatic pallet change. Just like new, the thing worked as expected. One loose wire and some new optical sensors, and we're back up and running.
Thanks Bill for all your help and ideas.

you can also add a macro to make sure the correct program and offsets are running when either pallet is loaded. I had an issue with a place I was at NOT LISTENING to me when I told them this. They crashed the first tool once a day it seemed like, because someone loaded one pallet and called up the other pallet program. While the program was basically the same, the offsets had to be different due to one fixture being 1/4 inch higher than the other. So I suggest doing this and that problem will never happen.

netsteeler said:

you can also add a macro to make sure the correct program and offsets are running when either pallet is loaded. I had an issue with a place I was at NOT LISTENING to me when I told them this. They crashed the first tool once a day it seemed like, because someone loaded one pallet and called up the other pallet program. While the program was basically the same, the offsets had to be different due to one fixture being 1/4 inch higher than the other. So I suggest doing this and that problem will never happen.

Click to expand...

Well, its a case of, is it the dog wagging the tail, or the tail wagging the dog.

With a machine that has a multi pallet pool and a scheduling system, its common for the program to be called by the pallet. Multi Pallet machines working lights out, commonly have measuring and broken tool detection of critical features and vulnerable tools. If an error is detected, work with the current pallet is ceased and the next scheduled pallet is called into the Work Zone. In this case, its fairly normal for the program to be called that is associated with the pallet. But its all about the the scheduling task.

Good practice is to call the Pallet from within the program being run. In this situation, correct Work Offsets for the Pallet being called should be in place. Particularly when running the machine unsupervised.

Its also common for each pallet in a multi pallet system to have a unique Input to the PLC so that the pallet number can be confirmed when its called to the Work Zone.

Regards,

Bill

Thanks for everyone's input. I haven't had any machine time to do any additional testing, but essentially I am trying to identify which macro variable tells the machine which pallet is loaded so I can take appropriate steps to ensure the correct actions are applied.

Because this is my situation:

huleo said:

Now the macros become harder for YOU but better if you have dumb operators as you can simply ask "uh, the program wants to start with pallet A, so is that like in the machine like now man?"

Click to expand...

I will look over the macro examples that have been provided and see if any work for my machine. Thanks for all of the input and glad others found answers to their issues also, that is what this forum is all about!

First, write down goals, results desired, who did this, who ordered this, expected work hours.
Write down expected workflow.
Even if it is your company, machine, and You alone.

If You document these things, Your stuff becomes valuable.
Often, quite a lot.

If You don´t, it becomes a liability.

--

I wont get into the specifics, but ...

Don´t You have any IO available.
Add some IO to make very sure You have pallet "n" in the machine.
A 2-pos switch would be good, one part insures pallet in machine, and second insures it is pallet "n".

Then read the IO in the code, compare to variable number, error on no match.

Very high risk on using variables to track state of expensive stuff.
At the very least, write state of variables into a file, with datestamp, and serial nr. of some kind.

Output log of operation into the file, before and after every pallet op, and maybe use a double file.
Operational tiny file has only a few lines, and is always copied into end of log file and then zeroed.

Operating pallets via sw sounds to me long-term past a few parts.
With very expensive potential crunches.

Endless uncommon corner cases exist in sw tracking stuff.

Guidelines:
Initialise/define everything in variables, check values constantly for existing and legal and sane values.
Log everything with time.

Errors might be timeouts, out-of-some-it-resource errors (open door, floppy drive ((not installed)), illegal date), out of memory, overtemp, whatever, endless.
Power error failure, estops, endless.


A called function / sub that always logs the action and state before and after the value change is a good idea.

Pseudocode:

ON:
See IO line pallet-2 go on, as hw_io_2.

Call change_pallet ( expected_value, to_value, hw_io_1, hw_io_2)

expected_value is current pallet value, 1.
to_value should go to 2 after change.

change_pallet macro:
write timestamp.
write expected_value, to_value, hw_io_1, hw_io_2 to file.
write "Initiating value changes, ts"
write called_value as to_value to file
write "Initiating pallet changes, to_value, ts"
call sanity_check( to_value)
call pallet_change (to_value)
write timestamp.
write expected_value, to_value, hw_io_1, hw_io_2 to file.

--
The point is to log state, ts,
expected action,
state, ts,
resulted action, ts
state, ts,
log "apparently_ok", ts.

--

The sanity checks and logs are very simple macros.
The logs will allow simple faster and more efficient troubleshooting.

Before and after logging will show what happened, when, and what was expected to happen, when.
--

I used to do a lot of this, previously, in vast scale for ten+ thousand simultaneous users over 130+ companies in 300+ sites.

--

My examples are a hint on making stuff work very reliably, with IT stuff interlinked.
Self_documented, proven, easy to maintain, not dependant on specific people or programmers, scalable.

Not at all specific to matsuura.