Messages

1

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 13, 2021, 06:51:07 PM »

My apologies, yes I am indeed talking about incremental movement, and your description is exactly as I observe on my machine.

In my opinion an MPG used in  incremental mode represent the most versatile, usefully safe means of manual control for both rapid  traverse and touch off.

Craig

No worries!

Yes, a MPG works nicely for user controlled movement.   

I don't believe that there are any bugs present in jogging. This thread just required some clarification and education in how the different modes are operating, and how the ESS works with Mach4.  Fin.

2

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 13, 2021, 05:14:07 PM »

Hi,

As soon as you let your finger off of the button in a continuous jog at full speed, the next time slice we pull from Mach4 should start showing the deceleration.  It will take the 0.15 seconds (or whatever you have it ESS motion buffer size set to) for that deceleration to work through the ESS's motion buffer.

That is not correct, I can with the jog increment set to 1mm cause the MPG to buffer up moves that carry on motion for several SECONDS after the MPG has
stopped moving. The same can be done with the on-screen jog buttons.

If the movement were restricted to the length of the ESS motion buffer that thread would not exist, there would be no need.....but the motion can persist for SECONDS

Craig

I said *continuous* jog mode where it will move at the full jog speed until you let go of the button and then it will decelerate.

You are talking about *incremental* jog mode.  In that version, you are repeatedly increasing the location of the destination, faster than the MPG commanded motion is being output to the motors.  Nothing is being buffered up in Mach4 when you spin the MPG wheel fast, but Mach4 realizes that the endpoint is still, for example, 3 inches away, and Mach4 will fulfill the command to travel that entire distance, even if it takes a few more seconds or minutes. Mach4 will keep telling the ESS how far to move for each time slice, until the commanded position is reached - Mach4 is doing exactly what it was commanded to do.   And again just for clarity, the moves are not buffered up (except for the fraction of a second worth of moves inside the ESS's motion buffer), the final position to go to for Mach's trajectory planner was being changed, and that is what keeps the motion going until that destination is reached.

Andrew

3

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 13, 2021, 11:23:27 AM »

As soon as you let your finger off of the button in a continuous jog at full speed, the next time slice we pull from Mach4 should start showing the deceleration.  It will take the 0.15 seconds (or whatever you have it ESS motion buffer size set to) for that deceleration to work through the ESS's motion buffer.

There is no such thing as an after run.   

You can't call a command to clear the ESS's buffer, other than by hitting EStop or pressing disable, and at that point motion will go to 0 with a clunk.

4

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 13, 2021, 10:58:32 AM »

...
Correct, the jog moves are buffered in Mach NOT the ESS.
...
Craig

The Mach4 trajectory planner calculates the position that every motor should be at at the end of every time slice (1 millisecond).  The ESS plugin calls that function to see where it should have all the motors at one time slice, and then calls it again to see where they are supposed to be at the next time slice, and repeats indefinitely.  Once the ESS plugin gets the position data for a time slice, it then sends that data down to the ESS's motion buffer for consumption.  The ESS's buffer will typically hold 0.15 second (up to 0.5 seconds) of motion or jogging data that it pulls from Mach4.  Mach4 is calculating and planning that data, but it isn't truly "buffering" that data.

5

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 12, 2021, 01:42:09 PM »

Hi Brian,

With the incremental jog, there is nothing wrong.  We have tens of thousands of SmoothSteppers out in the field running Mach, with lots on Mach4. We would be hearing endless reports of there are problems with jogging, if there was a problem, we don't. 

We do hear of reports where the soft limits being set up incorrectly (i.e. not how the Mach4 manual tells you to set them up), and then your exact issue is what happens.  That is because Mach is trying to do what it is told to do, even though it was told to do the wrong thing....   It is not a bug, when the Mach4 software is doing exactly what it was set up and told to do.

With regards to what you mentioned earlier regarding which button to press on the screen, that is why we tell EVERYONE to have a physical Emergency stop button.  You press it and the power is taken away from the motor drivers.   https://warp9td.com/index.php/gettingstarted/safety-information

Andrew

6

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 12, 2021, 09:21:58 AM »

...
In the case of the A axis runaway, I had switched to continuous jogging and the motion continued after the button had been released.  Not just a few steps, but inches of movement as I tried to stop it.  If this was a buffer finishing stored steps, there must have been several thousand steps accumulated and not flushed on button release.

I am still baffled about how to avoid this problem occurring again.

When jogging in continuous mode, the rules of acceleration and decelration are followed. If you have a slow acceleration - or a high max velocity - it will take time for you to get up to speed. Once you get up to speed, it will take the same amount of time to decelerate as it did to accelerate, and the same amount of distance to decelerate as it did to accelerate once you let go of the button. This means that there will be a bunch of deceleration motion produced once you let go of the jog button.  This is normal and what users expect and desire, because the alternative is to go from full speed to a dead stop with a nasty clunk that will start to tear your equipment apart.

Motion in the is consumed and destroyed, and replaced by zero motion commands when nothing is being commanded by a user or GCode program. If communications are lost the buffer empties out and then the SmoothStepper just stops dead.  There is no such problem as a buffer "run on" with the SmoothStepper, because the buffer will be drained in less than 0.5 seconds (by default less than 0.18 seconds) and then all motion will halt unless new motion is commanded by the user or a GCode program.

My next question is do you have your motor tuning configured correctly?  If you zero the X axis and then go to the MDI window and issue a G01 X1.0 F10 command, does the X axis move exactly 1 inch (or mm) in roughly a little over 6 seconds? Ho about all the other axes?  If it goes a lot farther than the 1 unit, or takes a lot longer than 6 seconds there are issues with the motor tuning. 

Andrew

7

Mach4 Plugins / Re: Mach4 plus Ethernet SmoothStepper with encoder or linear scale.

« on: July 20, 2019, 12:45:01 AM »

Hi Felicio,

The new product won't be available until later this year. 

It will have the same connectors and placement as the ESS.  It will have a step/dir interface (or CW / CCW, or quadrature, just like the ESS), but it won't have a +/- 10V interface. It will be able to perform a real-time comparison of the commanded position and a linear encoder and either EStop or perform a controlled slow stop.

It will support as many motors as the ESS does, which is 6. 

The price will be similar to the price of the ESS.

Andy

8

Mach4 Plugins / Re: Mach4 plus Ethernet SmoothStepper with encoder or linear scale.

« on: July 19, 2019, 12:24:39 PM »

Hi Craig,
 
You are correct, the ESS COULD be a feedback controller but Warp9 have expressed no interest in doing so. A major part
of that thinking is because each servo and servo drive is  a feedback loop.

The three main reasons we have not done this yet are:

1) Servos with their closed loop control solve the issue for the majority of users who need it.  This makes it a lower priority for us than other features that we have been delivering like Laser Raster and THC.

2a) In Mach4 a person could write their own lua script to monitor the distance of actual vs commanded and if the following error gets too large stop.  Admittedly this wouldn't be ideal and it would be better done in the Servo or the motion controller.   This would be happening all the time during GCode.

2b) If you are running in exact stop mode, whenever the motion stops and Mach receives an all stop position update, the lua script could see the reported position vs the glass scale position.  This is a better option, especially in the lost steps scenario, telling you if things got off.  But again only at stops not during motion.

3) The ESS doesn't have room in its FPGA for us to do it on board at this point.  We are planning to make closed loop control an option in our next product, where it would be in the SmoothSteppers firmware.

Andy

9

Mach4 General Discussion / Re: Dust hood

« on: May 31, 2019, 11:14:35 AM »

Hi Peter,

I am glad to hear that it was an easy fix!

Yeah, I use the log file all the time, it helps a lot to figure out what is going wrong!

Andy

10

Mach4 General Discussion / Re: Dust hood

« on: May 28, 2019, 07:45:05 AM »

No rush on my account, Peter!

Andy