Afternoon all,
Long time lurker, first time getting so frustrated and desperate I need to actually create a post for help!   

See error log below, I am trying to jog an axis using a macro and it errors out due to the fact that it fails to switch to "JOG" mode??
But there is no obvious way to do this?

Snipit of the section of code attached. The rest of the code that is not visible is commented out as I am trying to troubleshoot this part.

Any input would be much appreciated!!

Hi,
I'm not at all sure that what you want to do is possible.

Machs Gcode interpreter/trajectory planner can only have one master at a time. When you are running a Gcode job then you CANNOT jog, because
the trajectory planner is already assigned to the Gcode job. The only way you can do that is not just to PAUSE the Gcode job, but STOP the Gcode
job, thereafter the trajectory planner can be reassigned to Jogging.

Maybe this post will answer your question in mor detail:

https://www.machsupport.com/forum/index.php?topic=45605.msg289932#msg289932

The machine state reflects where Mach is and what its doing, you can't change it except by doing something that causes Machs internal status to change, a <Stop> for instance.

Craig

Thanks for the reply Craig, and Happy New Year!
You are right, it looks like I will have to go about this another way.

I am now working on telling the axis to jog via a button then have a bit of code in the PLC script wait for the "limit" to be triggered. Then stop the jog.
I have successfully been able to get the axis jogging but unable to get it to "stop" based on the "limit" signal.
More troubleshooting on my end! Once I have some better details I will report back if I need some assistance.

Is there a resource that properly explains the purpose of the PLC, Signal, and other scripts?
This is one area I find this software lacks is a proper explanation of when/how to use the signal script for example. So far it has been trial & error with a bit of forum/youtube surfing.

Cheers,

Hi,
jogging an axis and stopping on a Limit switch event is likely to fail.

Any event, like a Limit or Home switch, will be reported back to Mach but depending on your motion control board, and when the event
happened in its cycle the it may take 20-40 milliseconds to get back to Mach. By then the machine will have crashed.

Ordinarily Home, Limit and Probe events are handled by the motion controller because the motion controller can act on the event immediately, also
called realtime. In your case you have to wait for the motion control board to signal Mach....with some milliseconds delay, whereas what you want or
need is Mach to respond within a few microseconds...and that's just not going to happen.

For example the default cycle rate for an Ethernet SmoothStepper is 40Hz, or 25ms between data packets. Lets say your Limit switch activates at a time
t₀, and your ESS is 1/2 way through its cycle, then it will report to Mach at t₀ +12.5 ms.......and by then its probably to late.

Recall also that Mach issues trajectory data into a motion buffer. The default buffer length of the ESS is 180ms. Thus if you expect Mach to do something
quick you are going to be disappointed.

I have heard of people with good and modern PCs upping the cycle rate to 200Hz, and reducing the motion buffer to 20ms, but that still ends up with
delays of 0.5ms an 20ms respectively.

The only way for you to get this to work with any sort of accuracy is to have a REALLY SLOW JOG. Then it will not overrun too much before Mach gets to
hear about the Limit event and issue zero move trajectory data.

What is it that you are trying to do? Sounds like part way through a Gcode job you want to stop....jog to a Limit.....why?

Craig.

Hi Craig,
What I am trying to do is utilize the "Hardstop Detection" feature in the servos instead of homing switches by creating my own "Reference All" command (whether it be a function, script, etc.). The standard RefAll function does not work as it tries to detect the "All Systems Go" (ASG) command right away and sees it is true (because the motor is in a "ready state" when sitting idle). What I need is the motors to start moving first then start looking for the ASG signal.

In most other cases I agree that this would be doomed to fail. However, the Hardstop Detection function of the Clearpath Servos has some key features that allow this to occur and not "Crash". When the motor has Hardstop Detection initiated, it operates at a user set torque limit to avoid damaging the machine(eg.15%). Then the motor is can be commanded to move and "gently" find the hardstop. Once it does this, it runs an algorithm to "qualify" that it has indeed found the hardstop. Then it ignores any further "move" commands, in the homing direction, and sets the ASG signal high. Once the Jog commands have ceased the motor disables Hardstop Detection and goes to a full run state (accepting further move commands and using 100% torque).

In the motors homing settings, you set:
- The maximum torque when homing (I have it set to 15%)
    - this is the torque used to "hold" against the hardstop until it is commanded to move away by the user
- Whether homing is initiated on every enable or only the first enable after power-up
    - I have it set to initiate on every enable
- Direction and speed for homing

My intended process flow is something like this,
1. Press onscreen button to start "homing sequence"
       - X, Y, and Z motors are all disabled in the button script and register1 is set to a value ("1")
2. The PLC Script
       2.1 - IF statement when register1 equals "1" AND register2 equals "0"
              2.1.1- Enables the Z motor (initiating hardstop detection)
                  - Want to home Z first, then X and Y
              2.1.2 - Sends a Jog Velocity command to Z motor towards hardstop
                  - Z starts jogging home
              2.1.3 - timer0 is then initiated after 500ms that then sets register2 to a value of "1"
                  - This is needed to allow the motor to change states and "drop" the ASG signal
       2.2 - IF statement when register1, register2, and the Z-ASG signal are all "1"
                 2.2.1 - stop the Jog Velocity command
                 2.2.2 - Start a Jog Inc command to move the axis off the hardstop by a specific distance
                 2.2.3 - Stop the Jog Inc command
.                2.2.4 - Set register1 to "2" and register2 to "0"         
                 2.2.5 - Home the axis in place     
        2.3 - Sees register1 change to "2" and repeats steps 2.1-2.2.4 for the X axis, then set register1 to "3"   
              2.3.1 - For step 2.1 & 2.2, register2 would be "2"
              2.3.2 - For step 2.1.3, timer1 would be called and set register2 to "2"
        2.4 - Sees register1 change to "3" and repeats steps 2.1-2.2.4 for the Y axis, then sets register1 to "4"
              2.4.1 - For step 2.1 & 2.2, register2 would be "3"
              2.4.2 - For step 2.1.3, timer2 would be called and set register2 to "3"
        2.5 - Sees register1 change to "4", sends message box stating, "Homing complete" and sets all registers back to "0"


Hopefully....That all makes sense. I am sure there is a typo or something but the first cup of coffee has not kicked in yet!

Cheers,

Hi,
I'm not sure about all the registers and timers etc but otherwise I understand.

If you jog an axis until it hits a hardstop Mach without a Limit witch or similar to detect it  Mach will assume the
axis has continued and the DRO will keep increasing/decreasing. Lets say you eventually stop the jog the DRO may well
show the axis has moved 100mm or more 'beyond' the hardstop.

Whether you back it of the hardstop or not still means that the DRO will show that the axis has traveled beyond the hardstop by
some margin.

The problem you face now is how to set the machine coordinate to zero. There is no instruction or API that allows you to set a machine
coordinate. You may find it hard to believe, but you can't. You could not in Mach3 and you can't in Mach4 either. I know you are going
to point out:
LUA Syntax:
rc = mc.mcAxisSetMachinePos(
number mInst,
number axis,
number val)

But try it, it does not work in the manner you think, it changes the value of the G54 such that the Work Zero is zero.....but does not change
the Machine zero. By all means experiment with it....I did because I was expecting to be able to set the machine coordinate, and failed.

There is ONLY one way to zero a machine coordinate (or alternately set it to some non-zero Offset value) and that is to Home an axis.
You may remember in Mach3 you can 'Home in Place', well you can do the same in Mach4.

So the procedure would be:
1)Drive the axis to the hardstop unitl it times out or until a detect switch triggers
2) Back the axis off using an INC jog
3) Home-in-PLace....in order to set the machine coordinate for that axis. Note that the Home-in-Place check mark for this axis in the
Control/Homing_and _Softlimits tab must be checked, then you use:
LUA Syntax:
rc = mc.mcAxisHome(
number mInst,
number axisId)

Description:
Used to start an axis homing.

Craig

Hey Craig,
I am not sure about the registers and timers either...been a steep learning curve that is for sure. But great to know it at least makes "sense".

Understood, I knew that the DRO would read beyond the machine zero. The procedure you describe at the end of your reply is exactly what I was intending to do. Using Home-In-Place and the mcAxisHome functions.

I had used these previously when I had the motor homing settings to "home automatically" on every enable. Basically they would jog themselves home, detect the stop, and increment off the stop by the value you set in the settings whenever you enabled them. Only catch was trying to coordinate the Z axis first and waiting to home the rest until Z was finished. Then came the issue if you had to recover from an EStop. As soon as you "reset" the machine, the motors would start homing (really handy when you want to shorten your endmills that were still in a cut...ask how I know ).

I am hoping to work on this again a bit tonight and I will post the code if it works...or I have trouble.

I have used Mach3 up until recently and have been wanting to use this functionality of the servos for years. I am sure other Clearpath Teknic Servo users would love something like this as well.

The repeatability I feel will be much greater using hard stop homing controlled by the motors themselves. Plus it saves wiring and using switches.

Cheers,
Nik

Hi,

The repeatability I feel will be much greater using hard stop homing controlled by the motors themselves. Plus it saves wiring and using switches.

I disagree, with roller plunger snap action microswitches I get within 0.02mm every time and have done for years. If you want to add Index Homing over and above
Home switches then the repeatability is the resolution limit of your machine, in my case 1um.

Craig