Hello Guest it is March 28, 2024, 07:27:06 AM

Author Topic: Need help with M6 Macro, translating from Mach3 to Mach4  (Read 6901 times)

0 Members and 1 Guest are viewing this topic.

Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #10 on: October 02, 2018, 12:57:24 PM »
Craig, you were right. I was completely confused. I had tried to dig a little more through the initial information in the lua manual and got frustrated.

From there, my mach4 pc was a huge turd, and with other things going on in life I just put it on the back burner. Now I'm ready to take another crack at it.

I hadn't noticed your replies until now. I'm reading what you have posted and re-reading it. Hopefully it starts making some sense.

As for the "encoder" on the tool turret, it is just pulse indexing. As each tool is indexed, a pulse is sent. As tool 1 is indexed, a separate signal pulse is sent as well. So it's like an encoder but it's not technically. It operates in this order through the turret rotation:

Tool: Input 1, Input2

 Tool 1: 1-1
Moving: 0-0
 Tool 2: 0-1
Moving: 0-0
 Tool 3: 0-1
Moving: 0-0
 Tool 4: 0-1
Moving: 0-0
 Tool 5: 0-1
Moving: 0-0
 Tool 6: 0-1
Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #11 on: October 02, 2018, 01:49:13 PM »
I don't know how to store a state, but I am not totally new to state based programming. I didn't realize that this is what Mach4 uses. As I am reading and re-reading your posts I think it's starting to sink in just a little.

I think I could get by with something like this, just in the right language.

To index all six postitions something like this might work:

If input (the tool pulse) 1 is on, and input 2 (turret index) is on State =0 (Tool 1)
If Input 1 is on, and input 2 is off and state =0, change state to 1 (tool 2)
If Input 1 is off, and input 2 is off and state =1, change state to 2 ( I think a "dead state" may be nessicarry to prevent cycling/looping through all states automatically once the input/outputs are triggered).
If Input 1 is on, and input 2 is off and state =2, change state to 3 (Tool 3)
If Input 1 is off, and input 2 is off and state =3, change state to 4
If Input 1 is on, and input 2 is off and state =4, change state to 5 (Tool 4)
If Input 1 is off, and input 2 is off and state =5, change state to 6
If Input 1 is on, and input 2 is off and state =6, change state to 7 (Tool 5)
If Input 1 is off, and input 2 is off and state =7, change state to 8
If Input 1 is on, and input 2 is off and state =8, change state to 9 (tool 6)
If Input 1 is off, and input 2 is off and state =9 change state to 10
If Input 1 is on, and input 2 is on and state =10, change state to 0 (reset to state 0, and tool 1)

Tool Request is translated into state request. So if the machine is currently in state 0, and tool 1 is requested the machine checks the state (T1 State=0) and does nothing.
If tool 5 is requested the macro translates that into needing the machine to be in state 7. Since the machine is in state 0, it turns on two outputs simultaneously Lets call them output 1 and output 2. Output one is an enable relay that energizes the turret. Output two is the signal for the turret to move.

**How this turret works mechanically**
 When this turret is energized (output 1 on), it automatically moves in reverse and locks into position against a ratchet pawl. When the turret gets the "advance" signal (output 2), it moves forward. The ideal situation turns both the turret on, and then energizes it for a forward move. Once it is in position, turn off output 2. it will automatically reverse and lock into position. After a set time, turn off output 1 so the motor isn't constantly powered.


Once the outputs are turned on, the turret starts to move. As it moves it will be triggering the index and pulse "encoder signal", subsequently changing the states.

Once the turret is in the requested state 7 (Tool 5) position, it shuts off output 2 (the turret move signal) and then 10 seconds later it shuts off the output 1, de-energizing the turret motor.

Then if the state = the state requested by the m6, it exits the macro. Maybe it should store the current state. I am not sure. Or when we home the machine upon power up, the turret indexes to tool 1. I am not sure if or how states are stored however if we can save the current state it would prevent the need to cycle the turret through to state 0 and count up from there.

I know this is a long way from an actual program however I feel it is a solid outline of the macro. I just need the correct jargin.

« Last Edit: October 02, 2018, 01:59:16 PM by Havoc340 »
Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #12 on: October 03, 2018, 02:18:23 PM »
Hi,
I am digesting what you have said.

When you first turn Mach on it has no idea where the turret is. It will have to step through all the positions in turn UNTIL
it receives an index signal, ie tool 0.

What I propose is that we write a macro/function that advances the turret one position. It will be used not only to home
but later on as you which to advance to a given tool number within the M6 macro.

Given that this function will be called frequently it should be as efficient and fast as we can make it. Thus we wish to test:
IF the turret is ON (output1 is active) then activate output 2, ie advance one position UNTIL input 2 goes active.
IF the turret is not ON then turn it on and wait until input 2 goes active, ie the turret is accurately located at the current tool position THEN activate output 2,
ie advance the turret UNTIL input 2 goes active, ie the turret has advanced to the next consecutive tool position.

Does that sound right?

If you think that's feasible I will try a little code tonight after work.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #13 on: October 04, 2018, 12:18:04 PM »
I expected the turret to need to home, and cycle once to index itself to the first tool. This happens once the turret has been indexed and the first position established. Then if there was a way to keep track of the state the whole time mach4 was running on the computer (I expect it already does) then the turret would not need re-homed any more than the X or Z axis do.

I am also trying to understand the way you have worded your IF's.
I think I can simplify my explanation of the turret operation.

In order to advance the turret, you must turn Output 1 AND 2 ON simultaneously.
In order to lock the turret into place, Output 1 must be on, for 10 seconds by itself, with Output 2 OFF.  When output 1 is on by itself, the turret rotates backwards and locks against a ratchet pawl.
After the 10 second timer is met, Turn Output 1 Off. At this point, Outputs 1 and 2 are off and the turret is disabled.

To index the turret:
When it is time to home/index advance the turret, you will want to turn OUT1 and OUT2 on simultaneously.
When Input 2 (Index Input pulse) goes active, Turn off OUT2. wait 10 seconds. Turn off OUT1.
The turret is now indexed in the first position.

After the turret is indexed and home, this is what needs to happen for a complete tool change:
When a tool is called and it is time to advance the turret, you will want to turn OUT1 and OUT2 on simultaneously.
When Input 1 (Tool position pulse) goes active, Turn off OUT2. wait 10 seconds. Turn off OUT1.
The turret is now in the next consecutive tool position.

 Now that I know we have states to work with, I figured we would be giving each tool position it's own state. Having the "dead spot" state between tools would help "ratchet" the program through the states, ticking them up through the input changes.  That is how I am thinking about the program.  

 

Without knowing the intricacies of Lua structuring of things, and what needs to happen for something to happen I will say that however it ends up working is fine with me.


And thank you again for your time Craig! I know I am going to end up learning a ton from the way we are doing this. Seeing the way the code is put together to accomplish this task will give me a ton of insight how to get going with other macros. Maybe I'd even get the confidence to retrofit my other machine with a tool changer. I'd love to add a 4th axis to it, but the only way that happens is if I retrofit.
« Last Edit: October 04, 2018, 12:19:52 PM by Havoc340 »
Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #14 on: October 06, 2018, 05:43:17 PM »
Hi,
we can start doing some coding.

I think the best way to proceed is to put the two inputs and the two outputs in registers.

When Mach runs it has, broadly speaking, two chunks, one is the GUI chunk, the other is the Mach Core chunk. Only one can operate at a time
and the data in one chunk is not available to the other. Registers are the way around that, they provide a common repository for data and instructions
which can be accessed by any chunk or plugin throughout Mach.

First open Configure/Plugins/Regfile and make four new registers per the pics. Note you can use any names you feel are appropriate.

Once you have defined your new registers then go to Diagnosic/Regfile and expand the instance registers iRegs0. You will see your new registers and their current
values. Note that if you want to change a value just highlight it, click on it and edit it manually. Note also that registers can be persistent (or not).
If they are persistent then the values will be recorded in your profile.ini file at Machs shutdown and be repopulated when you start a new session of Mach.

Ok.....now we need to hook the input signals to Mach and then have Mach update the registers. Note that I'm dealing only with the input signals to start with.
Note also that I'm going to use Input #3 and Input#4 so that I can see the LEDs for testing purposes per my earlier post.

Will post the code shortly.....need to go and hang out the washing!   Its a bastard when real life interferes with your CNC... ;D

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #15 on: October 06, 2018, 06:35:34 PM »
Hi,
in the temp folder put this code, note that it overwrites the previous version of ISIG_INPUT3 entry:

Code: [Select]
mc.ISIG_INPUT3]=function(state)
local hreg=mc.mcRegGetHandle(inst,'iRegs0/ToolIndex')
if state==1 then
mc.mcRegSetValue(hreg,1)
else
mc.mcRegSetValue(hreg,0)
end
end,
[mc.ISIG_INPUT4]=function(state)
local hreg=mc.mcRegGetHandle(inst,'iRegs0/ToolPosition')
if state==1 then
mc.mcRegSetValue(hreg,1)
else
mc.mcRegSetValue(hreg,0)
end
end,

Note that after each table entry a comma is required to separate the next entry.
If you are happy with this then it is time to put it in its final location, namely the screenload script in the signal library SigLib{}.
Open the screen editor, and then expand the screenload script and note the SigLib{} table near the top. Paste in your two
new entries.
Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #16 on: October 06, 2018, 07:20:20 PM »
Hi,
note that when you exit and save the screen editior you will have saved a modification to the existing screenset.set.

If you are new to Mach4 then I would guess you already have a separate and individualized profile.ini file. What you may not
realize is that you should have a separate and individualized screenset.set as well.

The reasoning goes like this....if you are using wx4.set (as I do) and then you start making all sorts of additions and tweaks then when you next
update Mach to the newest and greatest build then you will also get a fresh copy of the newest and greatest wx4.set as well overwriting all your work,
and depending on circumstances you may not be able to get it back....double and triple bugger! >:D Ask me how I know.....I will have to answer PM as
the swearing filters would not permit me to post a frank reply!!!!

I recommend you go to the Mah4Hobby folder and find the screenset folder and make a copy of your favorite screen set with an individualized name.

Now when you run Mach go to View/Load Screen and you will be presented with a list of available screens which should include yours, select it and click Open
and that is now the screenset in use and will be recorded in your profile as such. Note mine is called ESSMillwx4.set. It will not be overwritten when you update.

It may be that I am insulting your intelligence by painstakingly laying out these things but I found they were exactly what tripped me up when I was learning.
If you feel slighted I apologise. I hasten to add that there may well be others following this thread and it might have relevance to them even if you find them
trivial.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #17 on: October 06, 2018, 09:05:34 PM »
Hi,
I like to test as I go. I could go and hook up a couple of switches to my ESS, but that's out in the garage. What I'm going to do instead is use a couple
of keyboard inputs to mimic the switches, means that I can do it all on my laptop.

It is not quite as straight forward as it sounds, you have to use a workaround to get it to work. Its such a valuable technique that it is
worth making the effort to learn, you will use it dozens of times over the coming months/years. I'm copying work that Daz-the-Gaz has already
done. Watch his video:
http://www.machsupport.com/forum/index.php/topic,31585.msg219180.html#msg219180

Open Configure/Plugins/Keyboard and add two new keyboard inputs, I used F1 and F2 and called them ToolIndex and ToolPosition respectively.
Now you need some code to go in the PLC. To start with make a temporary file in your temp folder....something like tempplccode.

Code: [Select]
--************************************************************************
--************************************************************************
--TEMPORARY TESTING CODE ONLY

local hsig1=mc.mcSignalGetHandle(inst,mc.ISIG_INPUT62)
local hsig2=mc.mcSignalGetHandle(inst,mc.ISIG_INPUT3)
if mc.mcSignalGetState(hsig1)==1 then
mc.mcSignalSetState(hsig2,1)
else
mc.mcSignalSetState(hsig2,0)
end
local hsig3=mc.mcSignalGetHandle(inst,mc.ISIG_INPUT63)
local hsig4=mc.mcSignalGetHandle(inst,mc.ISIG_INPUT4)
if mc.mcSignalGetState(hsig3)==1 then
mc.mcSignalGetState(hsig4,1)
else
mc.mcSignalSetState(hsig4,0)
end

--END OF TEMP CODE
--*****************************************************************************
--*****************************************************************************

Now open the PLC script and paste the code in just before the end.

You will have to close Mach and restart before these changes take effect.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #18 on: October 06, 2018, 09:14:28 PM »
Hi,
OK finally we can test what we have done so far.

start up Mach and open the Regfile Diagnostics page and pin it to the top. Make sure that on the jog tab the keyboard inputs are enabled.

Then on each occasion you hit F1 the input#3 LED should come on and the register iRegs0/ToolIndex should reflect your keypress.
Likewise if you fit F2 then input#4 LED should come on and iRegs0/ToolPosition should reflect the keypress.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Need help with M6 Macro, translating from Mach3 to Mach4
« Reply #19 on: October 06, 2018, 11:08:35 PM »
Hi,
sick of me yet!!!

Let me know if you stumble on any of the stuff so far.

Assuming all is good then we can start writing code to do things. The first thing we need is a macro to lock the turret.
I've called it m180....for no particular reason. Its generally considered that macros under 100 are Machs own....go there but
you may be trashing one of Machs macros. Anything above 100 is OK. Note there are some macros there  that you don't want
to trash either. From memory m161 and m162 are related to laser operation. You may not care that they get overwritten but
I would avoid doing so.

Another quirk of Mach4 is that when it reads a macro name it converts all upper case to lower case and strips out leading zeros and spaces.
Thus:
m180,
M 180,
m  0180,
M018   0
all point to the same thing, namely m180. Windows is not case sensitive and so M180 works, try that in Linux and you'll bomb.
It doesn't happen often but it does happen that if you use a non standard name because it 'looks nice' you can introduce an error.
I therefore name everything as Mach reads it, ie lower case, no leading zeros and no spaces. What you choose to do is up to you
but I promise on one of those rare occasions when it throws an error is going to leave you really pissed off.

Here is the m180 macro:
Code: [Select]
function m180()
-- Lock the turret.
local inst=mc.mcGetInstance()
local hsig=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT3)
local hreg=mc.mcRegGetHandle(inst,'iRegs0/TurretLock')
if (mc.mcRegGetValue(hreg)==0) then
mc.mcRegSetValue(hreg,1)
mc.mcSignalGetState(hsig,1)
end
local rc=mc.mcSignalWait(inst,mc.ISIG_INPUT4,1,11)
if (rc==mc.MERROR_NOERROR) then
elseif (rc==mc.MERROR_TIMED_OUT) then
wx.wxMessageBox('Turret failed to lock')
return
end
mc.mcCntlSetLastError(inst,'Turret Locked')

end
if (mc.mcInEditor()==1) then
m180()
end
Note I have done some things which you may question and may not work.

The first thing I've done is asked is the register iRegs0/TurretLock on or not. If its not on then turn it on.
Turn on the output Output#3, here I am assuming output#3 is hooked to the turret lock input of your turret.

Thats the easy bit. The next bit might take a little more thinking about. I have written a mc.mcSignalWait(inst,mc.ISIG_INPUT4,1,11)
instruction. You might like to read in the  API.chm document of the documents folder in Mach4. You will as you code Lua be reading
and re-reading...and re-reading....and re-reading the API document....and curse when you realize that its out of date, NFS have added new
stuff which hasn't even got in there yet!

Basically the instruction is saying 'Wait until ISIG_INPUT4 goes high (that's your ToolPosition signal), and time out after 11 seconds.
What I have done is assume that while you say it takes ten seconds for the turret to lock it might take less than that too. Thus when
the TurretLock signal is sent then Mach waits until the ToolPosition signal comes good. If that hasn't happened after 11 seconds you have a problem
and it will put a wxMessage on screen which you will have to clear. I'm not sure yet what you want to do in a fault situation.
If the turret locks within the timeout period then the you get a status message and the function completes normally.

Note that many of the API's have a return code, shortened to rc. The rc will give an indication as to whether the function has finished executing normally
or not. In this case I'm using it to detect a timeout which is an indication of turret lock failure.

Do you think that will work?

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'