I have built 3 cnc routers in the course of 4 years (on a small scale) and am now preparing for my next one which is retrofitting a CNC series 1 rigid ram Bridgeport. I started with Turbo cnc and quickly moved to Mach 3, which does the job, but not completely satisfied. I've gained some linux experience in the years and starting to like the system over windows, and microsoft products.

Has anyone else used Mach-3 and switched to using EMC ? Can you tell me about likes dislikes?

Also a quick question - how difficult is it to configure special function joystick devices, and possibly use a Contour-shuttle pro for an MPG encoder / positioner?

- Erich Stein

EMC can control closed-loop servos, so I would use mach only on stepper machines where the cutting loads are small (pcb-router, plotter etc.)

Configuring a jog-pendant or joystick should not be that hard, there are a couple of examples on the web and on the wiki.

I have built 3 cnc routers in the course of 4 years (on a small scale) and am now preparing for my next one which is retrofitting a CNC series 1 rigid ram Bridgeport. I started with Turbo cnc and quickly moved to Mach 3, which does the job, but not completely satisfied. I've gained some linux experience in the years and starting to like the system over windows, and microsoft products.

Has anyone else used Mach-3 and switched to using EMC ? Can you tell me about likes dislikes?

Also a quick question - how difficult is it to configure special function joystick devices, and possibly use a Contour-shuttle pro for an MPG encoder / positioner?

- Erich Stein

If I can do it anyone can this is my write up on hooking up a MPG pendant.

http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Hooking_Up_A_MPG_Pendant

What are you not satisfied with on Mach3? I use EMC2 btw...

John

Big John;

I am not satisfied with Mach-3. Though only a few outstanding bugs, one of them I found completely unacceptable -- where change the FEED/SPEED during g-code execution causes steppers to malfunction. A closed-loop system (to me) is also very important - and has taken a big back seat in the Mach-3 world. Also, the developers appear to be taking on some other software projects, which delay fixes and advances to Mach-3.

Windows is a good user interface, of course. I am not a fan for use with robotics, or other crucial timing sensitive applications. I prefer to use a linux system for this type of application and would rather take a chance and try something new. My experience so far building linux systems (used professionally a different environment and purpose) has shown me its more stable, consistent and configurable for engine server related platforms.

-Erich Stein

Thanks Erich for sharing that with me.

Was the feed changes during short arcs and or lines?

Thanks
John

Big John;

I cant say for sure specifically WHEN or WHERE the steppers would begin to malfunction. It started off as a wierd thing - and took months for me to trace down and pinpoint. If I ran a program and then just increased the FEED speed (simply by pressing "+" to increase speed beyond like 5%); then the steppers would just start randomly going MAD.
I thought at first for sure there was something wrong in my setup. Until after MONTHS passed and under every circumstance the problem will repeat and persist - on the router, and also in the test-bench.

I brought it up in the support forums and was told an array of different excuses. The only resolution was either to NOT use the feed-speed increase button above 125%, or to set the feed IN THE G-CODE TO 200% above what your target rate was, and set the default feed to 10% and increase up to 100% - but DO NOT exceed 125%.

This type of function is so basically necessary for g-code control.

Hi,
I'm sorry, I've never used EMC but I thought I'd try to shed some light on this feedrate override thing...

The reason that it is not advisable to go beyond 125% feedrate override in Mach3 is that it is not only the velocity that gets overridden but unfortunately also the acceleration. So if your setup is on the borderline acceleration-wise you may stall the motors when you override upwards.

Feedrate override is a necessary function for sure and IMO it works. I'm not sure (I've only seen a few in real life) but if you look at comercial CNC-controls, do you often see ones where FRO above ~120% is possible?

So, by posting your code with 2X your desired feedrate you can set the FRO to 50% and get the correct feedrate as well as having the possibility to override upwards.

Again, I'm just trying to explain what I think you were "hitting" and why. I beleive that originally the FRO in Mach3 was "locked" at 120% or something like that but people with more "capable" systems wanted "more" so it was increased.

There's not really a problem overriding above 125% if your motors can take it. The fact that the acceleration is overridden too is drawback for sure but that's how it is....

Hope that helps a bit.

/Henrik.

IMHO there is no reason to go past 120% with feed override. If your system is capable of more then it is not configured properly. If you programmed the G code wrong then you should fix that not twiddle with a slider past 120%...

I can understand how having acceleration tied to feed override and allowing either one to go past the machine limits is a big problem.

EMC2 does not allow that to happen. You set the machine limits in the INI file. The feed override or Fnnn will never go past the limits.

John

I pursued the FRO problem with great detail, and guarantee its not a matter of hardware. Months of my time were spent logging results in an analytic manner, with swapping equipment to the tune of at least 3 completely separate test environments.

I understand how the process of the data in a g-code program works with timing the output into a step/direction signal out the parallel port. I also understand the max top speed and acceleration will vary on hardware.

If I run g-code near the top feedrate on a Mach-3 system, and then push the FRO close-to or beyond that limit; makes perfect sense to see that problems will happen. I would expect a failure on EVERY system when pushed near limits.

If I run the same g-code at 1/3 the top feedrate on the SAME system, and push the FRO above 130% -- the motors still error and fail! Even though at 130% FRO the maximum speed and velocity of this system is still at 1/2 of its tested maximum speed and velocity.

For many people; all they want are simple mill operations which each portion is executed less then 30 minutes so it doesn't affect them very much. My artistic sculptures require HOURS of machine uptime - so changing the FRO is as common to me as a throttle peddle to a truck driver. Stopping the machine to reprogram g-code isnt something I feel comfortable with, when feed-increase should just do its job and work.

-Erich

If I run the same g-code at 1/3 the top feedrate on the SAME system, and push the FRO above 130% -- the motors still error and fail! Even though at 130% FRO the maximum speed and velocity of this system is still at 1/2 of its tested maximum speed and velocity.


Did you set the velocity and accel in motor tuning to 1/3 their normal values? That's what you needed to do for your test.

Also, about 2 months ago some changes were made to the FRO I believe. Have you tried the latest versions?

And btw, the FRO on our $150K machine only goes to 110%. :)

Hi,
Feedrate override is a necessary function for sure and IMO it works. I'm not sure (I've only seen a few in real life) but if you look at comercial CNC-controls, do you often see ones where FRO above ~120% is possible?

I've been away from commercial machines for a while. If memory serves correctly 200% override was common. In addition some controls (conversational types) had the ability to learn (change the program) as adjustments were made. Very handy for proving out a program. There's a reason a tailor built control costs big $$$.

In Axis there's a slider control that goes to 120%. Think that's the limit with all interfaces (not positive). The keyboard shortcuts only reduce feedrate. If there's another way of exceeding 120%, other than the gcode based solution, I'm unaware of it.

Oh yeah, and hands off, DrStein is ours now :) j/k

ger
What machine? Seems a strange limitation for $150k

Every machine in our shop has a feed override to 200% and spindle override to 150% but one older machine which is 120% on the spindle.
They all also have a separate override for rapid moves.
And in the parameters they have different max speed and acc settings for feed rate and rapid moves. The max speeds for rapids are faster then the max for feed rate moves but the accelerations are lower.

In emc - you can set the % override limit to whatever you want. (it is an INI setting.) It will still only override to whatever your maximum settings are. (it will never go over your max axis and traj ini settings)

http://www.electronicsam.com/images/KandT/testing/Screenshot-axis.ngc%20-%20AXIS%202.2.5.png

When I did the tests (and I will repeat again; which were very detailed studies over the course of months), I definately included setting the maximum velocity and acceleration to way below the systems maximum. The motors stall and error when I play with the fro above 100%.

I am certain that EMC2 isnt perfect and also has flaws and drawbacks; simply just because it exists. And I wont know if those problems outweigh the problems with Mach until I test and start using it. But I am trying to gather info.

So if I can set the FRO in EMC to a maximum, and by going to that value the motors WONT randomly move all over the place - UNLESS the speed/feed pushing hardware limits, then that right there answers one of the mysteries.

---
So about the encoder and joystick; I understand hooking up encoders, pushbuttons and switches to the parallel port, of course. How about configuring joystick interfaces?

-Erich

I pursued the FRO problem with great detail, and guarantee its not a matter of hardware. Months of my time were spent logging results in an analytic manner, with swapping equipment to the tune of at least 3 completely separate test environments.

I can relate to your frustration even if didn't build 3 machines. Testing can drive you nuts especially if the software is faulty.

I understand how the process of the data in a g-code program works with timing the output into a step/direction signal out the parallel port. I also understand the max top speed and acceleration will vary on hardware.

If I run g-code near the top feedrate on a Mach-3 system, and then push the FRO close-to or beyond that limit; makes perfect sense to see that problems will happen. I would expect a failure on EVERY system when pushed near limits.

My thinking differs here. You (the operator) should never be able to run the steppers/servos/machine faster than possible. Reaching the programmed machine limits should not result in a failure. Again just my humble opinion. Being an OEM and building machinery for a living if I turned out a machine that the operator could break just by pressing a button or twisting a dial I'd be out of work in a heartbeat.

If I run the same g-code at 1/3 the top feedrate on the SAME system, and push the FRO above 130% -- the motors still error and fail! Even though at 130% FRO the maximum speed and velocity of this system is still at 1/2 of its tested maximum speed and velocity.

This indicates a problem with the program and should not happen in any software that controls machines IMHO.

For many people; all they want are simple mill operations which each portion is executed less then 30 minutes so it doesn't affect them very much. My artistic sculptures require HOURS of machine uptime - so changing the FRO is as common to me as a throttle peddle to a truck driver. Stopping the machine to reprogram g-code isnt something I feel comfortable with, when feed-increase should just do its job and work.

-Erich

I was thinking of making parts not sculptures thank you for increasing my horizons on this.

John

When I did the tests (and I will repeat again; which were very detailed studies over the course of months), I definately included setting the maximum velocity and acceleration to way below the systems maximum. The motors stall and error when I play with the fro above 100%.

I am certain that EMC2 isnt perfect and also has flaws and drawbacks; simply just because it exists. And I wont know if those problems outweigh the problems with Mach until I test and start using it. But I am trying to gather info.

So if I can set the FRO in EMC to a maximum, and by going to that value the motors WONT randomly move all over the place - UNLESS the speed/feed pushing hardware limits, then that right there answers one of the mysteries.

---
So about the encoder and joystick; I understand hooking up encoders, pushbuttons and switches to the parallel port, of course. How about configuring joystick interfaces?

-Erich

In a nut shell EMC2 will not go past your limits in your INI file no matter what you do...

The Joypad is easy and there are several ways to get that done. The way I did is documented here:

http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_Remote_Pendant

John

samco how did you do that?

I guess I don't know everything about what I don't know yet...

John

easy as pie MAX_FEED_OVERRIDE = 1.2

1.2=120% so 4.0=400%

http://www.linuxcnc.org/docs/2.2/html/config_ini_config.html#sub:%5BDISPLAY%5D-Section

samco how did you do that?

I guess I don't know everything about what I don't know yet...

John

I know I know RTFM! LOL

Thanks
John

I was using Mach3 controlling a SX3 with a 600MHz HP computer fitted with 1/2 G Ram, running XP SP2. I experienced occasional pauses at any feed rate, and tracked it down to the low level driver emptying the queue because the CPU was off in the weeds doing something else, and was not keeping the queue charged. If the queue gets emptied, all axis movement stops, and if the axis movement was fast enough the abrupt stop can cause loss of steps.
That said, just the act of using the mouse to change the feedrate with the +/- keys can break the bank. Clicking on a new place on the green bar seems to cause the least amount of problems.
I have since upgraded to a 1.4GHZ computer form a later junk pile, using 1/2G RAM and Win2000 (which does not go and do stupid unstoppable XP weed munching) and can do anything with the FRO now.
One thing that still gives grief, and this is a software stuff up, not the queue being emptied is if you hit the <space> to pause, the current motion may be in the queue, the machine stops as requested, but when you hit cycle start, it MIGHT move too fast to the end of the move that was executing when paused. Great way to kill tiny cutters. I only ever stop it while cutting air, or sprinkle liberal M1's in the code so that it can be paused. I use very tiny cutters quite often.
Some don't do's with <space>
Never pause during a peck drilling cycle
Never pause during a circle.
If you have to pause very close to the end of a move.
Another thing that helps with FRO load, is disabling graphics display, and any other CPU intensive operation, like a camera view or sound.
Another thing that will screw up the queue feeding is CAM generated sequences of vectors all in the same direction like:
G1 X2
X2.2
X2.4
X2.6
... etc (Thats really dumb code generation)
Like as though somebody used their old dot matrix algorithms.
Should be:
G1 X2
X2.6
...
What CPU/RAM/OS combination are you using.
Beware of overheads caused by badly driven video cards.
If your mouse movement is jerky that's a sign of problems.
Maybe you need to run the Mach3 speed diagnostics.

Wow, now I'm really getting some nice info.

I agree with all the windows problems. I have tested computers with MIN and overkill hardware; all adding more hardware did was REDUCE the timing trouble - not eliminate it. Windows specifically is engineered from MS to be a multitasking switching operating system. Windows takes too much programming to write an application which generates a consistant waveform without interruption. I was looking into buying the ethernet or usb based hardware pulsing engine, just to solve the issue - but have been reading how new that technology is and how much trouble they've been having with that as well. Ideally, windows is much better for a user-interface then most everything else, but should be avoided for real-time application engines.

-Erich Stein

Hi,
I stand somewhat corrected about the comercial FRO range, the two we have at work, one SINUMERIC and one FANUC both goes to 120% or something like that but it seems like other (newer ones perhaps) indeed does go further than that.

Second, there has been a bug where the programed feedrate is disregarded after a feedhold but that one is said to be fixed in the later relases. If you are running the latest version of Mach3 and that bug is still present please, please report it to to ArtSoft (Brian Barker, nowadays)

There's also a setting in Mach3, called NoFeedrateOverride on queue or something like that. That setting - I think - will prevent the accelleration from being overridden BUT will also take longer time to take effect since the queue needs to empty before the new feedrate will be applied.

Every piece of software contains bugs, so does Mach3 and EMC2 and both have their limitations. For some, the limitation of one is a "killer" while it's perfectly "acceptable" for someone else. The important thing is that each and every one finds the software that suits them the best. But, with that being said, when a serious bug is reported and confirmed in Mach3 the goes out of their way to fix it - IMHO.

/Henrik.

EDIT: Oh, using a computer that is below the minimum requirements may result in behaviour that may seem like a bug but is really just the effect of using a too slow computer as some have noticed. ;-)

In emc - you can set the % override limit to whatever you want. (it is an INI setting.)

And that's why I post misinformation. Someone's bound to come along and correct it. It's a learning thing ;)

some of the original post has been snipped. (I'm old)



"I am certain that EMC2 isnt perfect and also has flaws and drawbacks; simply just because it exists. And I wont know if those problems outweigh the problems with Mach until I test and start using it. But I am trying to gather info."

-Erich

We dp our best to squash bugs as soon as we are able to verify them. And like someone said, the computer hardware sometimes gets in the way of proper operation. I have found occasional issues that bothered me and without exception these were fixed quickly. A recent one I talked with the IRC guys about took minutes to fix and get into the code.



"So if I can set the FRO in EMC to a maximum, and by going to that value the motors WONT randomly move all over the place - UNLESS the speed/feed pushing hardware limits, then that right there answers one of the mysteries."

-Erich

Once a lot of years ago I found a condition where very small INPUT_SCALE numbers -- this is the number of steps required to move one unit distance -- would cause a stepper to move very slowly when the machine was idle. That is the only time I've seen an EMC stepper misbehave. And I've been watching EMC move steppers for more than ten years now. I've seen them do bad things but in each case it was because I asked them to.



"So about the encoder and joystick; I understand hooking up encoders, pushbuttons and switches to the parallel port, of course."

-Erich

Certainly a parallel port is an inexpensive way to get signals into and out of EMC. Quite a few users pile bunches of parport cards in their boxes. EMC can handle most parport cards but there are a couple PCMCIA cards that just will not work. The drivers for them conflict with EMC's real-time code.

There are many other devices that can be used to get signals into and out of EMC. Some of these will handle as many as 72-96 different signals per PCI card and it's possible to use several cards at the same time. In recent months we have been seeing some pretty complex systems running with EMC2.

Our Hardware Abstraction Layer (HAL) works a lot like the telephone switchboards when I was a youngster. Real world switches and solenoids can be controlled by connecting to pins and those pins patched through software modules like encoder counters or logic elements, or Ladder programming, and from there to the motion or IO parts of EMC and back to the real world.



"How about configuring joystick interfaces?"

-Erich

There is at least one joystick module. I've not tried it because I don't think a joystick is a proper machine tool HMI. Did I mention I'm old. I much prefer a handwheel because it does no more than I ask it to and it ignores twitching.

If I look in the user space binaries, there is a hal_joystick executable. I believe that I could start that up and there would be a set of HAL pins that I can patch/connect stuff to. I'd probably have to figure out the location of the actual joystick port on my computer and include that in the loadusr command.

This executable is made from a similarly named source code file. I'll quote from the top of that source.

Quote
/********************************************************************
* Description: hal_joystick.c
* Joystick driver for HAL
*
* Author: John Kasunich
* License: GPL Version 2.1
*
* Copyright (c) 2006 All rights reserved.
*
* Last change:
********************************************************************/

/** 'hal_joystick.c', is a user space driver that allows HAL pins to
be controlled by a joystick. It uses standard Linux methods to
access the joystick, and should work with any joystick that Linux
recognizes. It is a user space program, so there is no hard
realtime guarantee, but under all but the worst loading it is
quite responsive.
*/
End quote

So it sounds like it worked for John when he wrote and tested it. He is a pretty systematic guy. I find him easy to believe. You'll also notice that the GPL license is applied to this source so you are free to study it, use it, modify it, and we only ask that you preserve the right of those both up and down stream from you to do the same.

Hope this helps.

Ray

A recent one I talked with the IRC guys about took minutes to fix and get into the code.


Well that beats mach-3. I have to wait for the 1 developer to be good and ready after they fiddle-farting around with their cam software and hopefully not decide to write some feature requests.


Certainly a parallel port is an inexpensive way to get signals into and out of EMC.

Yes. Unfortunately that means yards of wire back and fourth from the pendant and interface back to the control box. Using usb joystick interfaces, I can simply wire pushbuttons and switches to the usb board, and run a 4-wire usb cable back to the box. End of story.


Quite a few users pile bunches of parport cards in their boxes. EMC can handle most parport cards but there are a couple PCMCIA cards that just will not work. The drivers for them conflict with EMC's real-time code.


Well thats nice to know that I CAN put more then TWO in (if I wanted to). I see it is also compatible with modbus or otherwise hardware, which will handle lots more of i/o on a single unit card; and are available scaled up to industrial professional grade stuff.


Our Hardware Abstraction Layer (HAL) works a lot like the telephone switchboards when I was a youngster. Real world switches and solenoids


Good, I'll have no problem diving right into it and maybe modify it myself. I work as a telephony designer, installing customized integrated PBX switches using SIP protocols with VOIP which are linux based, to handle conference bridging, ivr, voicemail, etc.... It would probably take me a day or two to setup a test just to demonstrate to my customers how much fun it is to control a robot, from the other side of the country - using a plain old telephone call.


a joystick is a proper machine tool HMI. Did I mention I'm old. I much prefer a handwheel because it does no more than I ask it to and it ignores twitching.


I was planning to use a real MPG handwheel for jogging. Originally, I designed my interface with THREE handwheels - but unfortunately, thats another drawback to MACH-3; only allocates to use ONE MPG jogger at a time, I had to push other buttons in order to use the other wheels. I could go on about that trouble which also stole about 6 months of my time fighting at.


pretty systematic guy. I find him easy to believe. You'll also notice that the GPL license is applied to this source so you are free to study it, use it, modify it, and we only ask that you preserve the right of those both up and down stream from you to do the same.


Another loved concept of the linux community. Besides the fact that everyone helps to upgrade the project, its awesome to help and have the resources to be able to make my own modifications. I know its tough to code stuff, but I like a challenge.

Thanks for the advice Ray this is a big help!.

-Erich Stein

Yes. Unfortunately that means yards of wire back and fourth from the pendant and interface back to the control box. Using usb joystick interfaces, I can simply wire pushbuttons and switches to the usb board, and run a 4-wire usb cable back to the box.

-Erich Stein

The wire advantage is a real one and serial communication of these signals is one direction that professional grade CNC has moved. EMC has tended to stay away from USB because of the timing issues involved in it.

Getting around the latencies of a USB link forces motion system designers to separate position loop functions like task planning from the processor that is doing g-code interpreting and operator interface. What happens is that path is generated and passed over the link and later in time that path is modified using overrides. But unless the far side of the USB link is smart enough to rework the path based on new feedrates, you wind up with some really goofy motion -- like an acceleration that takes half a minute to get up to 720 degrees per minute and a path that needlessly rounds the corners between blocks of motion code.

I watched a demonstration of a small lathe a couple years ago. They had built it around a USB interface. There were truly weird delays at the start of each pass during single-point threading. Sometime it would just take off and do it, other times it sat for several seconds. I don't know this for certain but it seemed like the master computer had to compare the axis-motion-ready-to-cut signal and the spindle-in-position signal and send the "go now" signal to the axis drives. Negotiating this critical timing over the USB link seemed like it was a hit or miss thing.

Yes it would have been possible, to have written all of that into the outboard device. I believe that is the way most of the "DSP" based motion control cards work. That probably would have been the proper solution if USB was the only choice of communication channel. It's more likely that USB was chosen because it's right there on the front of the box and it supplies a bit of power to the outboard device.

There is a really active discussion about the nature of communication channels and outboard devices in the EMC2 community right now. I suspect we'll see some heated discussion at Fest next month. It is caused by the need for serial communication as we move to bigger and more complex machine control. It is also being pushed by several companies that work with us to build outboard devices.

We hold to several NIST design ideas. For those not familiar this is the USA National Institute for Standards and Technology. They are the folk who started the EMC project. One of these mantras they printed on coffee mugs. I've got two mugs gifted to me by NIST because I was one of the first to commit code when they opened the software to direct concurrent versioning input. That mantra is Sense -> Model -> Act. Think what happens to Sense -> Model -> Act when a communication channel with USB like latencies gets stuck between each of those where the arrows are.

That coffee mug shows a three by three matrix that looks a bit like this.

Sense -> Model -> Act
---|-------------|------------|
Sense -> Model -> Act
---|-------------|------------|
Sense -> Model -> Act

The bottom row is the most local loop, closest to the hardware. You could think of this as that outboard device itself. We have tended to use "dumb" interface devices because they allow us to see and manipulate everything that is happening in the real world that is connected to our software. With these devices we can watch, using Halscope, the shape of parport signals, even in the base thread at microsecond timings. So if we patch in a couple of HAL modules that do calculus we can watch velocity, acceleration, or even jerk at the encoder signals. We don't have to guess because we can sense.

We loose some of that ability if we separate the bottom most row of this matrix and talk to it over a serial link. Not all of the information can be passed from that lowest level to those above it. Our goal is to develop systems that allow us to pass all of the essential information between rows.

So, yes it might look like the EMC2 project is way behind and left in the dust. Fact is that we are just unwilling to compromise our ability to do accurate, repeatable, and safe machine tool and motion control just so that we can plug something into the front of the box rather than the back or inside.

Sorry for the long post. It's part of one of my topics for Fest. Hope it helps.

Ray

Samco's .ini example reminded me emc is configurable to the nth degree. We have the keyboard shortcuts for feed override -- 1 = 10%, 9=90%-- etc. Surely this is a default, not a restriction ? Maybe the keys can remapped for 110%->200% ? How about a seperate keypad? Maybe even a dial??

A desire to increase the feedrate on the fly seems perfectly reasonable. Talking here of the in program feedrate, not the machine configured limits. Back when I did shop floor programming with Mazatrol(Mazak) we would "write" the program with conservative feeds/speeds knowing it was possible to rewrite these while the program was running. Of course emc doesn't have that level of sophistication (yet), but the same kind of thinking applies. Sometimes it's hard to predict how a program will perform. Sometimes the alignment of the planets play a role afaict.

DrStein
It's clear you're an open source guy at heart, and head for that matter. Look forward to seeing where you go with this.

edit/ What goes on with the rapids when we double the feedrate in this manner? Will there be following errors? My guess is the limits set in .ini will prevent this?

btw: nice to see you her Mr Henry.

Getting around the latencies of a USB link forces motion system designers to separate position loop functions like task planning from the processor that is doing g-code interpreting and operator interface. What happens is that path is generated and passed over the link and later in time that path is modified using overrides. But unless the far side of the USB link is smart enough to rework the path based on new feedrates, you wind up with some really goofy motion -- like an acceleration that takes half a minute to get up to 720 degrees per minute and a path that needlessly rounds the corners between blocks of motion code.


Ray;

It looks like there was some confusion here. I wouldnt use A USB interface for position, closed looping, or encoder positioning, and otherwise realtime sensory input. For the USB, I would simply want to use pushbuttons for the operator interface, which - arent time-sensitive; like keyboard strokes. They make usb gameport breakout boards, where I can just wire 20 pushbuttons and assign them to the gameport pushbuttons.

But yes; I will gladly pass up a smoke & fire show of optional features for a stable and reliable positioning and sensory input system. I am now anxious to start testing the closed loop.


-Erich Stein

Apologies if this comes across as a fixation on a small part of this thread.


I brought it up in the support forums and was told an array of different excuses. The only resolution was either to NOT use the feed-speed increase button above 125%, or to set the feed IN THE G-CODE TO 200% above what your target rate was, and set the default feed to 10% and increase up to 100% - but DO NOT exceed 125%.


One of the joys of a commercial machining center is the ability to take it down to a crawl and then turn it up with a twist of the wrist. If mach3 works like emc, writing the gcode to 200% feed isn't optimal. Let's say you now decide 110% (~50% in real terms) is acceptable. The rapids decrease to the same proportion, a nuisance with a trusted program.

Reading a bit on this topic found an example of an mpg being used as a feed override. Unfortunately the operating range was not stated. There has also been talk of separate sliders for feed and rapid overrides.

So mach3 is down to one active developer? And a developer with side interests at that? If (god forbid) emc loses a core developer the door is open for new talent. I'm becoming convinced emc >> mach3.

So mach3 is down to one active developer?

Mach's always been developed by one person. It's just been transferred to a different one.

Some parts snipped.

Yes. Unfortunately that means yards of wire back and fourth from the pendant and interface back to the control box. Using usb joystick interfaces, I can simply wire pushbuttons and switches to the usb board, and run a 4-wire usb cable back to the box. End of story.You can use any USB input device you want, using the hal_input driver. Actually, this will work with any device that is recognized by the Linux input subsystem, not just USB. Devices of this sort include keyboards, mice, joysticks, joypads, keypads, knobs, and probably others I don't know about. In the example of a keyboard (an extra keyboard would be recommended :) ), the driver would provide HAL pins for each key and LED, so you could make any key act like a button connected to the parallel port, and the NumLock, CapsLock, and ScrollLock lights act like LEDs connected to a parallel port.
Well thats nice to know that I CAN put more then TWO in (if I wanted to). I see it is also compatible with modbus or otherwise hardware, which will handle lots more of i/o on a single unit card; and are available scaled up to industrial professional grade stuff.Err - well there has been some work done on Modbus, but there isn't a released driver yet. I hope to work on a modbus I/O system at the CNC workshop this year, so support should be forthcoming.
I was planning to use a real MPG handwheel for jogging. Originally, I designed my interface with THREE handwheels - but unfortunately, thats another drawback to MACH-3; only allocates to use ONE MPG jogger at a time, I had to push other buttons in order to use the other wheels. I could go on about that trouble which also stole about 6 months of my time fighting at.You can use as many MPGs with EMC2 as you have inputs to read them. You could set up 6 MPGs to jog 6 axes, plus have separate ones for feed override, spindle override, and jog increment control. Hmmm - I don't think you can set up *two* MPGs per axis, so you can set resolution with one and jog with the other - darn. ;)
Another loved concept of the linux community. Besides the fact that everyone helps to upgrade the project, its awesome to help and have the resources to be able to make my own modifications. I know its tough to code stuff, but I like a challenge.Even writing code is much less of a challenge these days. There's a great preprocessor called "comp" that automates a lot of the details of writing, compiling, and installing HAL modules. Once you have written your module, you can compile and install it with a single command:
comp --install my_module.comp
(this assumes that you have installed the emc2-dev package)

That said, there usually isn't a need to write new modules. There are a lot of building blocks that can be connected together however you want, so the need to create special-function blocks is greatly reduced.

Enjoy
- Steve

For the USB, I would simply want to use pushbuttons for the operator interface, which - arent time-sensitive; like keyboard strokes. They make usb gameport breakout boards, where I can just wire 20 pushbuttons and assign them to the gameport pushbuttons.


You can already do this with the non-realtime "hal_input" module, which can be hooked up in hal just like any other buttons or switches. This will work with any device that conforms to the USB-HID specification, which is most computer peripherals, but not necessarily any old hacked-together electronics a hobbyist might make in his garage. On a lark, I used hal_input to slave a simulated machine's position to a standard mouse, using the left mouse button for Z movement.

here's an example:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_Remote_Pendant

hal_input docs here:
http://www.linuxcnc.org/docs/2.1/html/man/man1/hal_input.1.html

you will need to know generally how to use hal of course

you will need to know generally how to use hal of course

Or you can get on the IRC and ask questions about hal till you know how...

John

Mach's always been developed by one person. It's just been transferred to a different one.

Yes, my mistake. I thought Brian Barker was a co-developer. It turns out he was more like an associate writing related software.

The open source model of many eyes on the code has some advantages. However happy Mach users are the majority on these forums. Enjoy.

Or you can get on the IRC and ask questions about hal till you know how...

John

One thing this thread has done is raise the issue of feedrate override. I have no experience with Mach but some with EMC and EMC2. I started up a couple instances of EMC2, asked a few questions on IRC, and tested. Here's how it works in the current EMC2 release.

Short answer. Feedrate override and axis max velocity are two separate individually configurable things. Feedrate override will not violate properly set values of maximum axis velocity.

The INI file has variables for MAX_VELOCITY for each axis, for the trajectory planner, and for the chosen graphical interface. An axis' max vel will allow speeds up to that value but no faster. Compound motion is also limited by the max velocity of the axes involved in the move but if the trajectory planner allows it, the tool tip motion can be faster than any single axis limit.

An example may help clarify. I'll limit velocity for each axis to 100 IPM. If the trajectory planner is set to 200 IPM a g0x5y5 command will allow the tool tip to move 141.4 IPM. The hardware limits are still honored but the g0 says, "get there as fast as possible." No hardware overspeed! At the same time we may use feedrate override will slow down a g0.

The real question becomes, "What does all this mean for feedrate override?" You'll remember that feedrate override is supposed to be tool tip velocity. For a three axis machine you can pump in as much override as you want. No need to deliberately fiddle with feedrates in a program and try to remember three years from now what you wrote in the part program. An individual machine integrator can set up feedrate override exactly the way she chooses.

Now it is possible for the different guis to display the max override different from each other. You might also see a displayed value that is larger than an axis can move but it will not drive the axis faster. Set your feedrate override scale from 0-600% if you like and you can really twiddle with cutting speed up to the maximum hardware speed.

Setting feedrate override is a GUI issue. Click on the display box and enter a number, grab a slider or click on one side of the slider with the mouse button, hook up a handwheel and spin it, or, NIST forbid, hook up a rotary switch and sense it's state. How you handle this is your choice when you set up the machine.

Actual cutting speed DOES affect cutting path because feedrate override and acceleration are a part of the data fed to the trajectory planner. It is sensed and then motion is modeled. If you get to very high speed, and you tell the interpreter, task planner, and trajectory to keep velocity constant you'll see some rounding. Feedrate override can modify actual cutting path but a part programmer has control over that.

Hope this helps.

Ray Henry

BTW -- the NIST forbid is a different topic.

The current situation with rapid override seems to be answered here
http://thread.gmane.org/gmane.linux.distributions.emc.user/6468/focus=6477

Final hijack of this thread. I'll refrain from any mention of deities, real or imaginary, in the future ;)