Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: mcardoso on March 10, 2019, 08:15:55 PM
-
Hi All,
I purchased my copy of Mach 4 today! ;D
I am finishing up the rebuild on the machine and have run into a few issues. They all seem to be unrelated but I figured I would save some space and ask for help for all of them in the same place...
System Setup:
Motion Controller: Ethernet Smoothstepper
Computer: Allen Bradley VersaView 5400 PC, 4 core Intel Atom E3845 chipset @ 1.90GHz, 4.0Gb of memory and runs Win 10.
Computer #2: HP Omen laptop, Intel i7 6700HQ 3.5GHz, 32Gb memory, running Win 10
Mach 4 version: 4.2.0.3804
Warp 9 Tech ESS plugin version: 232 (1.0.1.232)
1) When exiting the "Configure" -> "Control" menu, two general purpose outputs energize for a brief moment (regardless of machine state). These are tied to my power drawbar solenoid and emits a loud exhaust noise (although the cylinder doesn't move since both sides end up pressurized). I have these outputs tied to a screen load script and a signal script, but neither should do anything unless an external pushbutton is pressed.
2) When approaching my limit switches, some of the time when the switch is triggered I get a message in Mach 4 that says something to the effect of "ESS: Motor 0++ Limit triggered" and all axes become disabled. This is fast and very repeatable in position even when jogging at a good clip. Other times I get a message (from Mach I think) that says something like "X++ limit Active". It reacts very slowly and does not disable the axes or stop jogging (it does allow me to crash the machine). If I let go of the jogging key and press it again, it won't let me start jogging saying something like "Can't jog towards X++ limit", but again it doesn't stop the machine motion.
This issue also manifests itself when using "Ref all Home". When things seem to be working right, my axes home until the switch triggers, then reverse until the encoder marker is found. This gives home values repeatable to the .0001 mark on the DRO. However when mach is only showing the "X home switch active" message, the axis drive past the switch and contact the end of machine travel. The switch is energized and visible in the mach diagnostic window, but does not register to stop the homing.
It seems to me that Mach only registers the limit/home signals as a courtesy and relies on the ESS to stop motion or home an axis. It seems like sometimes my ESS is not registering the limit or home event even though the input signal is being received and transmitted to mach. Bu that is just an uneducated theory based on my observations.
3) When I enter M03, M05, and S#### commands into the MDI, my Step/Dir servo spindle often emits loud clunks when starting or changing speeds. This occasionally generates a bus overvoltage fault on my servo drive indicating the motor was requested to make some kind of instantaneous deceleration.
This behavior is NOT seen when clicking the spindle CW button on the Spindle section of Mach. I have not yet tried running the same code segments from a gcode file.
4) When exiting the Configure -> Control menu, keyboard jogging is disabled even though the button remains illuminated. I have to toggle the button to reenable keyboard jogging.
Looking for any thoughts. All these issues might be user error, but I would like to find a resolution.
Thanks!
-
Hi,
a few questions there....but I think several of them are related.
It seems to me that Mach only registers the limit/home signals as a courtesy and relies on the ESS to stop motion or home an axis
That is how Mach is supposed to work.
A Windows PC is not, nor ever will be, a realtime system, that is to say it cannot respond within microseconds to a home or
limit switch event say. Yet a CNC controller must absolutely be a realtime controller.
Mach (3 or 4), in fact any Windows based CNC software MUST be a buffered control system. Thus all movement instructions
issue by Machs trajectory planner get handed to the motion controller in a buffer, typically 20-100 ms worth.
The motion controller must however be a realtime device.
Art Fennerty wrote Machs original parallel port driver which made the PC's CPU perform in a near realtime fashion.
The PC programming world was astounded.....to my knowledge no one has been able to replicate his work. It was a direct
consequence of the (free) parallel port (quasi realtime) that allowed Mach3 to attain such a wide following.
Just as a matter of interest LinuxCNC IS a realtime system and that comes about because of R(eal)T(ime)E(xtensions) which
is applicable to certain Linux Distros. As a consequence LinuxCNC is not a buffered system.
Advance a decade and now Mach4 is native to and effectively requires an external motion controller. Such a controller
must handle all realtime functions. Some of which you are asking about, in particular, home and limit events. If the ESS
detects a limit event it should shut down all Step/Dir signals immediately, or within a few microseconds. If however the
ESS reports to Mach and then Mach issues an instruction to the ESS to stop all motion then the communication delays
(because of buffering) are tens of milliseconds, way too slow to be considered realtime.
When approaching my limit switches, some of the time when the switch is triggered I get a message in Mach 4 that says something to the effect of "ESS: Motor 0++ Limit triggered" and all axes become disabled. This is fast and very repeatable in position even when jogging at a good clip
This is indeed an example where the ESS is responding in realtime (less than 20usec or so). The giveaway is the report
beginning with 'ESS:Motor0............'.
Other times I get a message (from Mach I think) that says something like "X++ limit Active". It reacts very slowly and does not disable the axes or stop jogging (it does allow me to crash the machine).
This on the other hand sounds like Mach is in control and the communication delays both from the ESS to Mach and then
back again, from Mach to the ESS, are mounting up to allow a crash.
This suggests to me that you have certain events controlled by a Lua script (subject to comm delays) and certain other functions
which are (rightly) handled by the ESS in realtime.
The giveaway is your comment about 'X++ Limit Active' yet not causing an Estop. Mach does not automatically cause an Estop
if a limit is triggered, you have to program that behavior if that is what you wish.
In many industrial situations you cannot just program an Estop because you need to sequence a shutdown, something like
applying the brake so a heavy Z axis does not fall down and crush your operator.
When exiting the "Configure" -> "Control" menu, two general purpose outputs energize for a brief moment (regardless of machine state).
I suspect that comes about because the machine is disabled the outputs are going to their natural state, that is pulled high
(or pulled low) by your controller or BoB. Once Mach assumes control then the outputs assume their correct state, it just
in that brief moment when they are uncontrolled that results in a problem.
The only thing I can suggest is that you try reversing the sense of the signal. That would require an additional invert operation,
may be a relay, at or near the output. The only other way would to analyse the natural (pull up/ pull down) state of the pins
and reverse that sense.
Craig
-
Craig, Thanks for the quick response!
I think I roughly understand the interplay between Mach and a motion controller (and I totally agree that it is pretty amazing that Mach works at all). It seems to me that the ESS is not responding appropriately to my limit inputs occasionally, but there might be something else going on. I'll post this question over at the Warp 9 forum and see if anyone has experience with what I am seeing.
I have not modified any of the scripts except for a small chunk of code to control 2 outputs to my power drawbar. Any limit messages that I am seeing must be built into Mach.
I will play around with my outputs to see what all is actually happening. I understood that the ESS pulls outputs LOW when not in control, so I wouldn't expect anything to happen. Maybe there is something about my PDB script that is susceptible to false triggers.
Again, thanks for the response
-
A very good response Craig and it explained a lot.
-
In addition to the issues I mentioned above, I have 2 more:
5) Clicking The Jog Mode button (Continuous/Incremental) does not allow me to enter Incremental mode. I can change the incremental step size but it always jogs in continuous mode. Is there some special mode I need to be in to allow incremental jogging?
6) I have an MPG which is tied to the ESS Aux Encoder 0 and then that is tied to Mach's MPG#7. When I call mcMPGSetAxis(), I see the correct arguments in the log file, but no motion occurs. Is there a way I need to enable the MPG jogging?
-
Answered #6 myself. In the Mach Control MPG mapping, I had entered ESS Encoder 0 rather than ESS Encoder Aux 0. User error. :o
-
Are you trying to incremental jog using the keyboard or onscreen jog controls?
-
SwiftyJ, I would most likely want to use the keyboard for incremental jogging but I also have a touchscreen on the computer so that is an option. Neither allow me to jog incrementally. The mode is always set to continuous.
-
The onscreen mode only applies to on screen buttons (if referring to one of the default screens). Keyboard jog requires you to hold down the control key while jogging for incremental (if the keyboard plugin is configured as default).
-
Ah! That might explain the confusion. I'm coming from Mach 3 and I am used to placing the jog mode in Incremental before tapping the keyboard arrow keys to bump the axes incrementally. I did not know of the CTRL key stroke for incremental jogging. Can the on screen keypad only be placed in Incremental mode when keyboard jogging is disabled then?
-
Craig I have a question for you about Mach4 vs the Acorn system? I thought M4 was the answer to all of M3 problems and it was ready for prime time. I am now in the middle of going from M3 to M4 with the same Warp9 ESS that worked ok in M3. Now I am wondering? Is the new Acorn being so highly promoted on various Forums, really that much better? Its more money to switch over and I am just a semi-professional using on a 4x4 foot commercially made USA router. I do sell my work from time to time and I need something I can depend on.
-
Hi,
I have no experience with the Acorn system. From what I have read it is a polished and work ready system.
If you had the ESS and Mach3 working to your satisfaction then the ESS and Mach4 will be at least as good, and in
some circumstances better.
When all said and done both Mach3 AND Mach4 are GCode interpreters and trajectory planners. They take Gcode,
decode it and send P(osition)V(elocity) over T(ime) data to the motion controller. They support essentially identical
Gcode and so they perform nearly identically when running Gcode jobs.
The real advantage of Mach4 over Mach3 is its ability to be customized. Given you have a standard design router it
may well be that you need little or no customization at all. Therefore the strength of Mach4 will not be immediately
apparent.
Mach4 achieves its flexibility by a happy confluence of several design features. Mach is modular, and individual modules
can be added, subtracted or modified WITHOUT screwing up the rest of Mach4. This was a major failing of Mach3, you fix
one problem but break two other features elsewhere in the program. Mach4 has a consistent API, there again a marked
improvement over Mach3 which has a confusing set of attribute addressing modes depending on the 'era' that section
during which Mach3 was coded. Mach4 uses Lua which is a small, fast multi paradigm scripting language. The language is
deceptively simple but has a unique set of features that allow procedural, object oriented, functional and constraint
paradigms to be coded.
Depending on your ability and/or inclination those design features may not mean much to you. My opinion of the balance
of the features and the flexibility it confers is make Mach4 the most flexible Windows CNC solution on the planet. Notwithstanding
the good feedback from UCCNC users I still believe Mach4 exceeds UCCNC in terms of customization.
The only true competitor, in terms of customization, is LinuxCNC. Of course Linux is not every ones cup of tea and coding in
C/C++ is not trivial either. None the less LinuxCNC has been adopted by OEMs and modified and polished into a highly
functional CNC solution. Haas controllers are probably the leading example of how LinuxCNC can be adapted.
Thus if I were an OEM looking for a CNC software solution that I could adapt and integrate into my machines there are two
preeminent choices, Mach4 or LinuxCNC. That reduces to the choice between a buffered Windows solution or a low jitter
realtime Linux solution. The question of 'Linux vs Windows' is a whole debate in itself. I personally am familiar with Windows
and therefore choose Mach4 as my solution.
The truth is, of course I'm no OEM and neither are you, and therefore is all the flexibility that Mach4 offers actually required?
In my case the answer is no......but I like it none the less. If you also answer 'no, that kind of flexibility it not what I need or
want' then your choices of CNC software solutions expands somewhat, certainly UCCNC comes into consideration as does
Acorn.
My only misgivings about UCCNC and Acorn are that they are a single proprietary solution (software and hardware),
that is to say if you adopt Acorn say then you are obliged to play their way....and pay accordingly. I don't mean to
suggest that either company is about to 'entrap' customers for profit nor that NFS and supporting hardware manufacturers
can't do the same thing. That is a matter for you to decide. The history of NFS and Warp9TD, the two manufacturers
of my CNC solution is amply demonstrated for me to purchase from them.
You might ask why have NFS gone about developing Mach4 in the way that they have.....all in all Mach4 does not have a good
name from either new converts or those updating from Mach3, to such people Mach4 seems overly complicated.
My contention, and this is my own opinion only, is that NFS need OEM customers to survive as a business. You and I might
buy one Mach4Hobby license each for $400 combined as a one off sale. An OEM might buy five Mach4Industrial licenses
a month for $7000. Bryanna and others have stated that NFS values Hobby customers, and their continued support of
this forum and continual updates to Mach4 at very generous licensing conditions prove it. None the less NFS must look
to the development of Mach4 in such a manner that they can attract OEM customers. That is the driving force behind
the development strategies and priorities of Mach4.....and I love it!!
I do sell my work from time to time and I need something I can depend on.
My opinion is that Mach4 is more reliable and better supported than Mach3. If Mach3 has been adequate in the past then
Mach4 will be at least as good in the future. If you do not require any or very little customization, or are prepared to pay for it,
then Acorn is a reasonable choice.
Craig
-
Thank you for a very informative answer, it helps a lot.
-
Craig, Awesome Reply.
For anyone curious about where I am at on some of the original questions:
1) The signal script contains a short chuck of code that says "if the button is pressed, extend the drawbar, if the button is released, retract the cylinder and start a 500ms timer to turn off the solenoid" Apparently this gets scanned when exiting the Configure/Control menu and since the button is off, the retract solenoid fires. Doesn't seem to happen every time. I will figure out a way to interlock this so it doesn't happen, but it doesn't cause harm other than a startling pop when the solenoid fires.
2) This was a big deal to me when it was happening, but I have been unsuccessful in recreating the problem since I posted this. I'm chalking it up to a glitch in Mach/ESS that hasn't happened again. I am using the home to marker/Index feature of the ESS and love the functionality. It repeats to the .0001 on the DRO's, where the limit switches themselves are not nearly that accurate (nor do they need to be). I'm crossing my fingers I no longer have homing/limit issues.
3) This is still a big issue for me. Any M03/M04/M05 call in the code causes a clunk or two when accelerating, changing speeds, or decelerating. This behavior is seen using MDI or GCode, but it doesn't seem to happen with the M03 button on screen (although I could be wrong on that). This used to fault my drives on an overvoltage which tells me the pulse train was delayed ever slightly and the drives responded by attempting to instantaneously decelerate.
The Allen Bradley Ultra 3000's I am using have a setting called Slew Limit which sets the maximum acceleration /deceleration that the drive will allow even when the Step/Dir input goes faster, however the correlation of position between Mach and the drive is lost when this limit takes effect, so I would prefer not to use it. I currently have it set at twice the Mach 4 programmed spindle acceleration and it has gotten rid of the overvoltage issue (however I can still hear the clunks in the spindle drivetrain). This issue is not seen/heard on any of the coordinate axes, only the spindle.
-
If this is only happening with the spindle, and you have an ESS, you should explore
the ability of the ESS to control the spindle acceleration.
-
Regarding Acorn:
I recently set up an Acorn based system for a friend. The setup was more straight-forward since hardware and software are well integrated. The user interface was was very polished and easy to use. The documentation was very complete. Whether or not it is the better choice depends on the user. For those who want to tweak, modify, and tailor their system to work exactly the way they want it to, and are willing do the extra work, Mach4 is the better choice. Those who are willing to accept the functions and workflow of the machine more-or-less as-is, and would rather get straight to cutting rather than configuring, Acorn might be the better choice.
That said, despite terrific support from Centroid, my friend was not able to get his system running (thus my involvement). More straight-forward does not mean it is easy.
On an aside: One of the things that happened when I transitioned from Mach 3 to Mach 4 was that I had to learn more about how everything works. In the end I am happy that this led me to a much better understanding of how things happen "under the hood" which has been immensely helpful in all aspects of the work.
-
My only misgivings about UCCNC and Acorn are that they are a single proprietary solution (software and hardware)
Most UCCNC and Acorn users will tell you that this is a big plus. When the software is updated, the firmware for the hardware is updated along with it.
You're never waiting for the 3rd party hardware manufacturer to update their plugins.
-
Related to #3 on the original post, I have continued to have some issues with the spindle whenever it is accelerating, changing speeds, or decelerating to a stop. Not sure if it is a wiring, Mach, or ethernet smoothstepper issue, but the servo seems to receive delayed or missing steps which cause significant clunking in the drivetrain and occasionally a drive fault. I have a workaround to limit the servo acceleration at the drive level but this isn't the best fix.
I have a support ticket in with Warp9TD (whose support is A+) so it will be interesting to see where it goes.
Few trends showing what should be a smooth ramp in commanded speed of the spindle motor, but has a dip back to 0rpm which causes aggressive jerking of the spindle:
Note that the graphs are inverted to -5000 rpm due to the drive polarity, but it doesn't make a difference.
-
Hi,
in my earliest days of Mach (Mach3 and parallel port) I did not have any home switches. It was common for me to 'home
in place' at the center of my table. What I noticed then is I got a small 'blip' each time any axis passed through zero.
It was repeatable.
If the machine were at X=-50mm and I issued an MDI G0 X50 as it passed through zero I could hear it. It did not appear to
lose any steps but I could still hear it.
Not long after when I had fitted home switches and the home now occurs at the lowest lefthand point of my table
I cannot (short of crashing!) pass through X=0 or Y=0 and so have never noticed the problem since.
Could it be that your machine is passing through its machine home location?
Craig
-
Warp9TD confirmed the spindle issue I am seeing is some sort of bug. They are working towards a solution.