Hello Guest it is October 20, 2019, 10:44:08 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - smurph

171
The obvious question is why do the axis jog planners  not use the default units set by the user? Surely that overcomes the problem?

I don't know  why the Reset button is even there, it didn't exist in my Mach3 screen that I use. The only time I've pressed it was when Mach4 became unresponsive for any reason and I thought that might get back in control. I intend to remove it because I have no idea what it's supposed to be used for.

Mach 4 is not Mach 3.  About the only thing they have in common is that they are windows programs that run G code.  If you want to make a comparison, Mach 4 is probably a lot more like a Fanuc than it is like Mach 3.  The reset button is normally on all machine controls (Fanuc, Ysanac, Fidia, etc...), Mach 3 being an exception.  It is there to put the machine into a known state.  For instance, what if you were running a program with cutter comp and stopped it.  And you wanted to restart it from the beginning.  Well...  comp is still in effect!  Or what if you ganked the machine state running MDI commands?  Reset ensures that the machine is put back into its' know state (no comp) before you run the file again.  Reset is all about safety.  You can spot the reset button on a Fanuc quickly because it one of the most used buttons and is probably worn more than others.  

Steve

172
I see what is happening now.  It is not changing on its' own.  The config process destroys the axis jog planners and recreates them with the default of inches.  Nothing, at this point, will set the jog units other than a reset.  Pressing Reset will put the control in the proper mode.  

Ok, I'll call that a bug.  But you don't press reset after a config?!?

Steve

173
Or finally, perhaps someone at Mach might take this bug seriously and fix it!

It isn't a bug.  I explained in a earlier post that the jog units will follow the machine units mode.  The jogging USED to be ONLY in machine native units.  But we got so many support tickets about that so we made it follow the units mode.  Damned if we do and damned if we don't...

Steve

174
rc = mc.mcJogSetUnitsMode(inst, axis, mc.MC_UNITS_METRIC || mc.MC_UNITS_INCH);

Also,

unitsMode, rc = mc.mcJogSetUnitsMode(inst, axis)

The mode of the machine may override it.  Meaning if you called mcJogSetUnits() to set the jogs to metric and then executed G20 in G code, the jogs will be in inches.  And vice verse. 

Steve

175
New video:  https://youtu.be/dtEKxEudc8M

Striplar, turns out this is easy!  But...  there is a bug.  I guess nobody had tried to use this stuff before.  You are definitely a %1-er!  LOL  The bug will be fixed in the next development version.  Until then, use the method in the Test.mcs file or the new SetJogIncrements() in the video. 

Steve

176
I didn't remember who said it when I was writing the above post.  But this is exactly what Craig was referring to.  Luckily, most of the stuff people want to modify is less complicated than jogging.

Hi,

Quote
Everyone who attempts to change the way the jog works is going to go through these mental gymnastics.
You want to CHANGE the way it works therefore you assume responsibility for the effort.

Look under Diagnostics/Regfile...expand the various categories and have a look.

Craig

The only mental gymnastic one has to go through is to understand this point.  And don't assume that there is a one line function call that will do what you want either.  Sometimes, that is the case though!  :)  But the stock jog actions use numerous API functions behind the scenes to give the functionality that is does. 

Developing something that works the way you want it to may not be easy.  It may require learning something and it may take a while to learn it.  And that is why this forum exists, to help people learn.  Learning is something we all can do.  Some consider it a chore while others consider it an adventure.  A lot of the time this involves some amount of experimentation.  At least that is what I tell myself that I was doing when I stuck my fingers into a light socket as a kid.  :)

Steve

177
The problem is that there's no joined up easy to understand way to find out about how Mach4 hangs together. I don't ask questions because I'm lazy or stupid, I ask them because they aren't obvious.

So far, I've not made any sense of how Mach4 decides what size jog increment to use, how to set that with a script and how to read it back. That's not for lack of trying, it just doesn't appear to work. Maybe I'm missing something that's blindingly obvious, but mcJogSetInc() returns an error and mcJogGetInc() doesn't return the value of the increment it's currently jogging at.

Well, technically speaking, it isn't how Mach 4 hangs together, but rather how the GUI hangs together.  Mach 4 has a core that can be run by any GUI that is written using the Mach 4 API.  We ship an example GUI called wxMach.exe that is basically a static front end.  So what we are technically talking about here (now) is the functionality of the GUI.  Mach4GUI.exe is the GUI that is dynamic and can be customized.  It provides FAR more functionality than the static wxMach.exe GUI does.  For instance, there is no LUA scripting in the wxMach.exe and you can't add or change the display beyond that of any other windows program.  

So we have established that the Mach4GUI.exe provides a lot of functionality that the user needs to run a machine.  One of the functions it provides is jogging.  But it is important to note that it is a SCREEN implementation of the jog.  So the internals of the GUI keeps track of the increment in its' own container.  It calls API functions such as mcJogSetIncr() etc...  This is done per axis in the core so the GUI is actually doing something more than setting just one global increment.  It is doing it for ALL coordinated axes.  But that is not all it does.  It also keeps track of the jog mode (incremental or velocity) too.  So that when you press the jog button on the screen, it does that particular jog mode.  So there is a lot built in here.  

mcJogSetIncr() and mcJogGetIncr() are basically APIs to use to STORE and RETRIEVE a jog increment.  They don't, in fact, DO ANYTHING.  When you cycle the Jog increments in the GUI, the GUI will use mcJogSetIncr() to store the jog increment that is selected.  Mainly as a means of communication to the rest of the Mach world what increment it will use the next time an incremental jog is performed.  But it also tracks what it was told to use in its' own internal variable.  Why?  Because there may be an MPG or some other control device (panel) that has jog buttons on it.  The increments my be chosen by a buttons or some rotary knob.  Say the user has an MPG and they switch to the .001 increment.  Then they do some jogging and stuff with it and put it down.  Do they want the MPG to always control the jog increments?  Or do they want the jog increments to remain set by the device that is actually used for the current jogging activity?  Most want them separate and that is the default behavior of the screen.  

Some MPGs may only have a hand wheel and no increment switching available.  This is the reason for mcSetJogIncr().  It allows for the screen to set the increment and the increment to be retrieved by whatever is running the MPG with mcGetJogIncr().  So the GUI's stock behavior WILL update mcSetJogIncr() if you toggle the jog increments with the stock jog control buttons.  To let the rest of the Mach world know what the screen's current increment is.  mcSetJogIncr() has no other function than that.  The stock jogging implementation doesn't use mcGetJogIncr() to retrieve this increment before jogging.  It uses its' own internal variable.  So that the screen's jog increment can be different than the other devices that my be used to jog the machine.  

Now, let's take a look at the API function that the GUI (or any other thing that may be running a jog will use) uses.  Namely mcJogIncStart().

In LUA:  

number: rc = mcJogIncStart(number: inst, number: axis, number: dist)

Notice the distance parameter.  This is what drives the incremental jog's distance!  Not what was set by mcJogSetIncr().  There is no function like mcJogIncStartUsingLastSetIncr().

Mach 4 was designed so that no scripting is required to use the stock screen sets.  It is meant to cover 98% of the use cases.  One can wire up a machine to a motion controller, map the necessary I/O to signals, and run the machine from just the screen and mouse.  All of this functionality is "canned" or "shrink wrapped", if you will.  However, it also provides a means of changing the default behavior, for whatever reason.  Don't like it?  Not applicable to the task at hand?  Rather do it your own way?  All of these are valid.  But understand this:  Now the work and functionality is up to you.  So to change the jogging functionality, you will have to write your own and provide ALL of the functionality.  Fortunately, you have the tools of the API to accomplish this.  What I think you are wanting to do is do your own thing but also use the stock jog actions.  We all want to have our cake and eat it too, right?  :)

What does the stock jog functionality do?

1. Provides a jog mode variable. (incremental, velocity)
2. Provides a jog increment variable. (for the increments)
3. Provides a table of jog increments.  
4. Provides canned actions to drive the jog buttons based on the above variables. (toggle jog mode, jog an axis, toggle increments).
5. Calls mcJogSetInc() to let the rest of the world know what the screen is doing.

So all of this will need to be duplicated/provided.  Or...  you can try and use the stock functionality and merge it with yours.  HOWEVER, I do suggest that once you deviate from what is stock that you would be better off doing it all.  So that YOU know what is going on all of the time and don't get bit by some stock behavior for which you may not have accounted.  Because if you do "modify" the stock implementation, you pretty much need to know how it all works AND how to manipulate it to begin with.  That is something that is in my head and it will probably NEVER be documented because 99% of the people using Mach don't kneed to know it.  EVER.  :)  Never the less, I have attached the test file that I used in the video to show how to do what I think you are wanting to do.  But to do it right, you would need to edit all of the jog buttons, remove the stock actions, and write scripts to do all of the required functionality.  

But can you guys imagine what kind of crap would be on this board if the stock jog buttons/actions didn't exist?  I mean, it would be apocalyptic!  "You mean that I have to write LUA code to jog an axis!!!", etc...  

In the attched file, the SetJogIncrements() function now uses a screen API called scr.DoFunctionName().  You can open the screen editor and use the names of the stock button actions to get the name.  This function ONLY works with the primary instance (no instance parameter), so multiple instance controls definitely need to handle this type of thing differently.  

Steve

178
Guys, it isn't this hard!  :)  I made a video that might help. 

https://youtu.be/hISdOAVaAbM

The registers are there for external access to the current jog increment that the screen is using.  So that some plugin or external script can tell what the current increment (the screen's notion) is. 

For example, say you have a script that needs to change the jog increment and then change it back to what it was AFTER it is done.  Otherwise, those registers are not needed.  Don't use what you don't need. 

All of this can be done with mcJogGetIncr() and mcJogSetIncr().  The screen will follow these increments, as shown in the video.  And I WILL say this...  If I could learn how to use that damned video capture software and create that video, then you guys can certainly learn this LUA stuff.  I will not fib, it was frustrating.  I made several videos that were just blank screens with audio.  But guess what?  I didn't have a clue about what I was doing!  :)  Once I figured it out, and the light bulb in my head came on, it all started working as it was meant to.  Same goes for Mach. 

Steve

179
The motion controller plugin will always "set" the positions.  The mcMotionGetPos() is for OTHER plugins to get the positions, if needed.  Things like the ModuleWorks cut simulator, etc...  The counts are doubles because to some controllers use real numbers for their counts!  To me, a count is a count is a count.  There is no in between.  As in, you will never see a quadrature encoder give a count like 1024.765!

But the world of stepper motors begs to differ.  The Ethernet Smooth Stepper is one that uses real numbers for counts.  And it DOES smooth out the pulse train.  Somehow.  I haven't quite figured out how and honestly don't want to hurt my brain trying to.  :)

Probing.txt is old and the gospel should be the one in the API manual under the plugin development category. 

Steve

180
The motion controller plugin should only deal in counts (or steps) so that it remains unit agnostic.  So this is usually an integer number, but it can be a real number as well (micro stepping, etc..).  All of the conversion to the native machine units is done in Mach.  The position (in counts) is then divided by the counts per unit in the motor tuning tab to derive a position in the native units of the machine.  

For the case of a probe strike, the motion controller should:

1. Latch the probed strike position (in ABS counts) for each motor.
2. Decelerate all of the motors involved in the probe operation to a stop.
3. Report the probed positons (in ABS counts) to Mach.
4. Report its' current positions to Mach (because Mach doesn't know where it all stopped!)
5. Tell Mach that the probe operations is complete. (This will sync the real world position to Mach's planners.)
6. Ack the stop report requests.  

All of this is documented in the API manual if you want a more technical explanation with the API calls that are to be used.  

Anyway, the Mach 4 motion control plugin paradigm is designed to be dumb as a rock.  All a motion plugin needs to do. basically, is follow the ball.  And tell mach when the requested movement is done, in most cases.  Homing and probing as about as complex as it needs to get, as these are real-time processes that just can't be handled in Mach.  

What is reported by the motion plugin ends up in 5071-5076.  The actual machine positions with no offsets applied.  Then the current offsets are applied to those and they go in 5061-5066.  So Michael is correct in stating that if what ends up in 5071-5076 will affect what is in 5061-5066.

Steve