Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: mouridsen on January 23, 2019, 03:41:40 PM
-
Hi
I have made a button to save the machine position and work offset position into the register. This works!
I have also made a button to load these positions again. It works for the work offset position but not for the machine position.
I use the mc.mcAxisSetMachinePos but it doesn't seem work.
I the ScreenScript.lua there is a WriteRegister & GetRegister function.
Any ideas?
-
Hi,
I use the mc.mcAxisSetMachinePos but it doesn't seem work.
Have a closer look at the API.chm for msSetMachinePosition, note that there is no 'description' which certainly doesn't
help but look at the usage example. It is of course using C syntax....
Usage:
// Set axis 0 fisxture offset.
int mInst = 0;
mcAxisSetMachinePos(mInst, 0, 0.0 /* set part zero */);
Note that it says 'Set axis 0 fixture offset'.....that implies that it does NOT set the machine coordinate. This may seem
strange or contrary to your expectation but my experimentation concludes that you cannot use this API to set the machine
coordinates.
With any sort of luck smurph will read this post and he may be able to confirm my interpretation.
My understanding is that there is only three ways to change the machine coordinates:
1) <Ref All Home> or <Ref Axis>, ie the machine will drive to the home switch location and reset (or alternately set the
machine coordinate to your programmed offset) your machine coordinate.
2) <Ref All Home> or <Ref Axis> when the axis does not have a home switch in which case it will home in place.
3) Move the machine either by jogging, MDI or Gcode
Note that none of those methods allow you to arbitrarily set the machine coordinates.
Craig
-
I use these scripts for setting work offsets.
I find the center of almost everything I machine, so I made these buttons to make it go faster; I touch off one side (x,y) and call it zero, then I touch off the other side (respectively) and press these buttons that take the current coordinate position, divide it by two, and update the axis position.
BUTTON SCRIPTS
--X = "X / 2"
local inst = mc.mcGetInstance()
local val = mc.mcAxisGetPos(inst, mc.X_AXIS)
local XPos = (val /2)
local rc = mc.mcAxisSetPos(inst, mc.X_AXIS, XPos)
But, that's not going to help; I just realized you want to change the Machine Coordinate. mcAxisSetMachinePos... I've never tested it.
I'm curious, why do you want to set the machine position? Generally you don't want to mess with the machine coordinates, it will alter any and all work offsets you have set; if you have home switches, using the Axis Position (Work Offset Positions) should work just fine; but like I said, I don't know what your intentions are.
-
It sound like it is not possible.
The most important function is to save the work offset position and load it again and that works.
My reason for doing it was to make it possible to save the position for all coordinates and then be able to shut down the machine and pc (for what ever reason) in a random position. Then I could start it all again (the next day maybe) and load all positions and continue where I stopped.
The bad thing about this approch could be that I might loose a step when I turn off and on for the stepper drives.
Now I have to rely on the Homing and proximity sensors. I have seen that they should be quite precise.
I still think it could be nice to have the possibility :)
Brian
-
Hi,
My reason for doing it was to make it possible to save the position for all coordinates and then be able to shut down the machine and pc (for what ever reason) in a random position. Then I could start it all again (the next day maybe) and load all positions and continue where I stopped.
The correct approach is to at the start of the new session reference (home) your machine and THEN using your stored
work offsets resume the job from where you left off. For this to be effective you need accurate homing. I use roller plunger
microswitches and achieve 0.02mm repeatability. Using index homing would allow even closer (1 um) repeatability
but as it transpires 0.02mm is adequate for me.
You can, as you have done, use persistent registers, or you could write them to a file. I do this with circuit board programs.
The file name of the stored data is the same as the Gcode etch file with "OFFSET' appended.
Note however that such explicit methods are strictly not required because the current Work Offsets (G54, G55, G56....etc)
are stored at shutdown and restored at restart, ie they are stored in persistent registers.
If you shut down your machine and record both the work coordinates and the machine coordinates and then restart the machine
and restore the coordinates at restart. That would work IF the machine did not move, you can usually be assured that is so.
However if you use microstepping with your steppers then in effect your machine will 'move'. Lets say you use 1/8th
microstepping. At the moment of shutdown (when you recorded your coordinates) the machine was at the third of the eight
microstepps between full step positions. When you restart your stepper driver will be at a fullstep position and you will
have lost that 3/8th of a step. Having said that the loss of precision is likely to be small and may well be tolerable.
There is a workaround that would allow you to proceed with that solution if you wish. It relies on doing an effective
'home in place' at the end of your session and then at restart programmatically unlinking the motors and doing a 'dummy
move to the stored original machine coordinates' doing another 'home in place'.
I have one this before, it was confusing as hell but it did work. Let me know if you want further details.....you poor sick little
puppy!
Craig
-
Hi
The correct approach is to at the start of the new session reference (home) your machine and THEN using your stored
work offsets resume the job from where you left off.
We are fully aligned 8) This will be my way of doing it. Thanks!
Brian
-
Like Craig said,
Having home switches in place will be the best option. That way you can start your machine in the morning, home it, and your Work Offsets will already be stored into the Machine.
Also, when you home the machine, you are able to use soft limits.
-
Hi,
Quote
The correct approach is to at the start of the new session reference (home) your machine and THEN using your stored
work offsets resume the job from where you left off.
We are fully aligned 8) This will be my way of doing it. Thanks!
Aww crikey Brian, I thought, even sort of hoped, that you were a sick puppy!!!
I recall when I tried to develop a workaround to programmatically set machine coordinates I did have to think very carefully
about homing, coordinate offsets and so on. I learnt a lot as a result.
Even having developed a workaround the standard procedure I and Chad are promoting is still preferred, and how I do it
for instance. I have not found a legitimate use for my workaround.....maybe its only value is what I learned in pursuit of it!
Craig
-
With any sort of luck smurph will read this post and he may be able to confirm my interpretation.
Craig is right. No way to set machine coordinates via script (on purpose). Well, unless you get very creative and just want the practice.
-
Thats another pain in the aris.
Got a Fagor controller on one of my lathes, shut it down and restart it and it saves all positions prefectly. A quick check to confirm and jobs can be resumed without having to re-home etc. Never failed.
The Devs should expose the methods to do this. Seems easy enough as they RESET the machine Coords to zero on a restart.
More headaches....
-
Thats another pain in the aris.
Got a Fagor controller on one of my lathes, shut it down and restart it and it saves all positions prefectly. A quick check to confirm and jobs can be resumed without having to re-home etc. Never failed.
The Devs should expose the methods to do this. Seems easy enough as they RESET the machine Coords to zero on a restart.
More headaches....
It depends on the motion controller. My machine with a Galil on it does this perfectly so it isn't a Mach limitation. HOWEVER, what if someone bumps the table? Game over. Only homing or ABS encoders will ensure proper positioning.
Steve
-
I know what you are saying, I just don't understand why restoring the shutdown parameters isn't a basic default. I mean why not? It seems counter intuative to arbitrarily reset the machine Coords to zero.
Not heard of the Galil - have you got a link?
thansk
-
Hi,
if you have parameters, in this case coordinates, that you want to save.....that's what the ScreenUnload script is for, save the data to the .ini file and
restore the data at the next startup during the first pass of the PLC.
There is a particular procedure (other than Homing) where you can set the machine coordinates at will, it's a workaround and not too difficult, and is in any case
automated.
Craig
-
I know what you are saying, I just don't understand why restoring the shutdown parameters isn't a basic default. I mean why not? It seems counter intuative to arbitrarily reset the machine Coords to zero.
Not heard of the Galil - have you got a link?
thansk
https://www.galil.com/ (https://www.galil.com/). However, note that the Galil is not a plug and play motion controller. You must understand how a Galil works to effectively integrate them into a CNC machine. Also, while there are things like position retention available with the Mach/Galil plugin, other things like lathe threading and mill rigid tapping are not available. So research and decide.
I think everyone that wants something a certain way wishes for it to be a "basic default". It is human nature. :) However, most motion controllers set the machine coordinates during the home operation because in all cases except ABS encoders, the correct thought is that the position is undefined until the machine is referenced. Otherwise, why would there even be a homing/referencing feature? Mach 4 has lots of screw mapping and Z leveling features that Mach 3 never had and they simply depend on the machine being referenced. Referencing the machine at startup simply ensures correct operation EVERY time. Not some of the time or times where nobody bumps the table. Even though the Galil remembers the previous positions, I do not use it because it takes a mere 20 seconds to home my machine and then I know my fixture offset is correct. No guessing or checking.
But again, this is not a Mach 4 limitation. Mach 4's notion of machine coordinates is whatever the motion controller tells Mach it is. If you wish for your shutdown positions to be retained, ask your motion controller vendor for that feature.
Steve
-
Hi,
I had Mach4Hobby and my ESS motion control saving the machine coordinates at the end of a session and then writing those saved values to the ESS
at the next start years ago. There is a trick that you can pull using HomeInPlace and HomeOffset that effectively hoodwinks the ESS into writing an arbitrary value into
the machine coordinate register.
I never really used it. Like Steve every time I start Mach I Home....always....no matter what. It takes but a few seconds, no guessing, no inaccuracies.
I never turn my machine off, unless perhaps I'm doing some maintenance or alteration or maybe the power has faulted out....a fairly rare occurrence.
My mill has been sitting powered on for the best part of two months since the last time I powered it down to fit a new fourth axis. I ocassionaly re-Home
but have yet to find a time when the reference has somehow 'slipped'.
The only time that I've ever really wanted the feature that Rimmel wants is when the machine crashes, by that I mean a software crash or something along those
lines. In that event the machine does not shut down gracefully and so the Screen Unload script never runs anyway.....so whats the point?..... and under those same circumstances
I would not expect the ESS plugin to be running and therefore retain machine coordinates either. Even if the plugin were running would I trust that the machine coordinates had not
been corrupted?.....no I don't think so.
There are features that I wish Mach4 and the ESS had, but this is not one of them. Features that help me make parts certainly, but this feature does not do that.
Craig
-
For what I do with that machine it's really helpfull.
"From Mach3 to Mach4
Mach4 is completely new! We cannot stress this enough: Mach4 is not an upgrade for Mach3. It is faster, more responsive, and provides a platform for expansion, modification, and new features. The changes requested by many Mach3 users were simply not able to be completed because of limitations in the Mach3 code. Mach4 is our response to the limitations and requested changes for Mach3."
Unless you simply want it to save it's state over shutdown....
-
Hi,
Unless you simply want it to save it's state over shutdown....
I've posted that it can be done, twenty or thirty lines of code, or does it have to be programmed for you by NFS?
I did it myself not long after I started using Mach4, say 7.5 years ago. I found it less useful than you might believe, but I did have
it working. I've updated I don't know how many times since and that code didn't survive and was not useful enough for me to be bothered
to recreate it.....but its not rocket science.
Craig
-
Hi,
Unless you simply want it to save it's state over shutdown....
I've posted that it can be done, twenty or thirty lines of code, or does it have to be programmed for you by NFS?
I did it myself not long after I started using Mach4, say 7.5 years ago. I found it less useful than you might believe, but I did have
it working. I've updated I don't know how many times since and that code didn't survive and was not useful enough for me to be bothered
to recreate it.....but its not rocket science.
Craig
Well yeah it can be programmed using a "hack or "workaround" which is hardly ideal.
Should you really need to do it for a "Hobby" installation?
-
Hi,
Should you really need to do it for a "Hobby" installation?
Well no.....in fact you don't. Once I had fitted proper and decent Home switches I found that I didn't need this facility at all and I let the
code for it 'lapse' six years ago because I didn't use it.
Craig
-
steve
im agree with you ,but now with abs encoder , i read position ,how can i set it on mach?
****i use with home in position and put the value as offset , but its not very good
for example the axiss always have mistories movment( its not noise ,its small move that comand from mach)
-
steve
im agree with you ,but now with abs encoder , i read position ,how can i set it on mach?
****i use with home in position and put the value as offset , but its not very good
for example the axiss always have mistories movment( its not noise ,its small move that comand from mach)
I don't think I fully understand your question. Maybe you can post a new thread about it?
Steve
-
sure
-
Hi,
as smurph has pointed out that behaviour is set by the motion controller.
The motion controller that is the subject of this thread is the ESS. The ESS reports to Mach a 32 bit integer value corresponding to the machine coordinates.
That value is multiplied by the step/unit value and that is the machine coordinates in native units which in turn populates Machs DROs. To my knowledge
ALL Mach4 ready motion controllers work that way. Thus the ONLY way to change the machines coordinates of Mach is to CHANGE the integer value fed to Mach
from the motion controller.
There is nothing that NFS could or should do about it, its not a Mach4 issue.
In the case of the ESS there are two ways to change the integer value, either by moving that axis OR Homing....no other choices have been made available by Warp9,
and in fact I don't see that its really required either, although OP seems to disagree. The work-around I and Katz have used is to use the HomeInPlace instruction, which
requires no axis movement or Home switch involvement, and HomeOffset. It's adequate.
I note this discussion is being had on the Warp9 forum and Andy is thinking about modifying the ESS code to allow a user to arbitrarily set the machine integer value.
Craig