Hello Guest it is March 28, 2024, 11:22:01 AM

Author Topic: 5 axis Pedant for Mach4 with Smootstepper ESS  (Read 1806 times)

0 Members and 1 Guest are viewing this topic.

Offline FiveO

*
  •  17 17
    • View Profile
5 axis Pedant for Mach4 with Smootstepper ESS
« on: March 16, 2020, 01:30:16 PM »
Hi,

What 5 axis Pedants work with Mach4 and ESS?
Re: 5 axis Pedant for Mach4 with Smootstepper ESS
« Reply #1 on: March 16, 2020, 01:41:03 PM »
I personally like the generic pendants that come with a big pigtail and a ton of wires. If you aren't using the 3rd port of your ESS, this is a great use for it.

https://www.ebay.com/itm/Universal-CNC-6-Axis-MPG-Manual-Pulse-Generator-Pendant-Encoder-for-FANUC-System/182325817276

https://www.ebay.com/itm/HEDSS-6-AXIS-CNC-Pendant-100-MPG-JOG-Encoder-ISMM2080-5V-TTL-Line-Driver-E-STOP/261853344399

Andy did a great write up of LUA scripting a pendant.

https://warp9td.com/index.php/faq/faq-pendants-and-mpgs
« Last Edit: March 16, 2020, 01:43:46 PM by mcardoso »
Re: 5 axis Pedant for Mach4 with Smootstepper ESS
« Reply #3 on: March 21, 2020, 10:23:38 AM »
Those USB or Serial ones require a plugin for Mach 4 (unless you plan on writing your own interface - which is doable if you are very comfortable in LUA and embedded programming). There are only a few supported ones right now, and I can't remember which off the top of my head. I know the normal complaints are lag between the device and Mach 4 due to the communications.

My biggest reason for selecting a wired unit was that I could use the ESTOP in my safety string. An ESTOP over a network (like
USB or wireless) is absolutely no good from a safety perspective.
Re: 5 axis Pedant for Mach4 with Smootstepper ESS
« Reply #4 on: March 21, 2020, 03:03:35 PM »
Hi,
I have used a VistaCNC P1A for several years and and perfectly happy with it. It is four axis capable.
The P3 and P4 models from the same company are six axis capable.

I've never had an issue with the Estop running on a USB connection.

You may have noticed that Profibus, Ethercat and CanOpen all now run safety data over the network for industrial
machines.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: 5 axis Pedant for Mach4 with Smootstepper ESS
« Reply #5 on: March 21, 2020, 06:42:36 PM »
Hi,
as far as the comms delay that Mike (mcardoso) refers to I have not noticed it in practice.

Like any MPG, if you spin the pulse generator wheel quickly and have a high or significant step increment set in
Mach4 it is entirely probable that you will exceed the axis speed and therefore end up with motion commands in the
buffer which will in turn result in after-run even once you stop spinning the wheel.

This used to happen to me when I had a 1mm movement increment per step set in Mach4. It was very easy for me to
end up with 20-50mm of movment stored up in the buffer......and no amount of panic on my part was going to change
that. I found the problem less pronounced when I set the maximum increment per step to 0.5mm per step, but my normal
setting is now 0.1mm per step. I can cause after-run if i really really try to spin the wheel as fast as I can but under normal
operating circumstances I don't end up with any after-run and can yet still jog plenty fast enough.

It has made me realise that after-run is not a fault, its what Mach is supposed to do....it did something stupid because that is
exactly what I asked it to do. Now that I have a realistic increment set the 'problem' has evaporated, I can jog as quickly
as I want or need and yet have the resolution for all but the most demanding of positioning ops.

As Mike pointed out the USB comms impose a delay between the pendant and Mach.

Follow this sequence of events:
1)The trajectory planner is otherwise unoccupied. The planner has been issuing a long string of zero movement PVT
(position velocity over time) commands to the motion controller in one millisecond intervals.
2)The motion controller has a buffer (180ms is the default buffer length in the ESS) full of zero movement commands
and so the machine is stationary.
3)The trajectory planner receives a step command from the VistaCNC plugin to execute a single increment step
on the selected axis.
4)The trajectory planner issues a string of PVT data slices to enact that movement, lets say 5 slices so that the move
takes 5ms.
5)180ms later (the buffering delay) the motion controller recieves the non-zero PVT data and the motion controller issues
the pulse streams for the axis motor to move as required.

Consider step 3) a little more closely. When the pendant MPG wheel is advanced one click the circuity within the pendant
assembles a frame of data to send to its plugin (here I am assuming a VistaCNC type plugin), then the frame of data is
communicated to the plugin, and thence to Mach. I would assume the plugin-to-Mach communication to be in the usec
range, likewise I would assume the hardware can compose the data frames in usecs, therefore the only (significant) delay
is the USB frame rate....around 8-12ms.

The total delay from the MPG pulse to the pulse be enacted by the motor is 190ms being the sum of the buffering delay
and the USB frame delay. Were it possible to eliminate the USB delay, the total delay from MPG to motor is 180ms.
Clearly the total delay is to all intents and purposes determined by the buffer delay NOT the USB delay.

Consider now the situation that you have a hardwired MPG to you BoB/ESS combination. When the MPG is rotated one click
the BoB/ESS hardware being essentially instantaneous composes a data frame to send to the ESS plugin which
in turn communicates to Mach. Machs trajectory planner then issues the same 5 non-zero PVT data slices, which is communicated
to the ESS via the same 180ms buffer.

The default controller rate for the ESS is 40Hz. Thus it will communicate frames of data back to it s plugin ( and thereby Mach)
with up to a 25ms delay.

The total delay from MPG pulse to motor pulse is 205ms, assuming the worst case timing of the MPG pulse realtive to
the ESS data frame timing, to 180ms, assuming the best case timing.

The total delay is still largely determined by the buffer delay.

Thus I disagree with Mikes contention that communication delays imposed by a USB (or other serial communication protocol)
place pendants at a disadvantage relative to hard wired MPG's, the total delay is determined nearly exclusively by the
buffering delay of the motion controller and is the same in both circumstances.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: 5 axis Pedant for Mach4 with Smootstepper ESS
« Reply #6 on: March 23, 2020, 09:03:28 AM »
Well shoot. Now I feel bad for making Craig write a long response! I haven't used a USB one so I'll defer to his expertise on them being good to use! The longer cable of the USB ones would be nice. My pendant has a 6' pigtail cord that could do to be a little longer.

I do stand by the safety over networks comment though. All the safety signals that go over Ethernet/IP, EtherCAT, Profibus, CANOpen, etc. are all specially formatted for extra CRC and packet redundancy, as well as strict timing requirements for packet arrival. Lots of the leading companies in Industrial Automation have their own protocols for accomplishing this (the one I am most familiar with is CIPSafety on Ethernet/IP). This COULD be implemented with Mach 4 and USB but it certainly isn't at this time. I know most of us don't even use a safety system beyond wiring into Mach 4's ESTOP input, but coming from industry and designing safety systems for industrial equipment, I can't feel comfortable trusting a USB signal with safety encoding to stop my machine (especially if my hand was stuck in it!).