Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: b_ankenb on June 28, 2019, 12:41:37 AM
-
I'm new to this forum, so sorry if I make some mistake.
However, I've been looking everywhere to see if it'd be possible to send a PWM signal over the parallel port, from a Geckodrive G540 to a PC, as input that Mach3 would recognize (maybe a 50% signal does something, while a 75% does something else).
We're building a machine that needs an input to the computer to tell it to either reverse feed, continue forward, or stay stationary. Our plan was to just use the 4th axis limit switch on the terminal block's pin 4 (we don't have a fourth axis), but I think that's meant to transmit a normal binary on-off signal.
Will that pin work if we somehow send a PWM signal through it? If not, what's the best next move?
-
However, I've been looking everywhere to see if it'd be possible to send a PWM signal over the parallel port, from a Geckodrive G540 to a PC, as input that Mach3 would recognize (maybe a 50% signal does something, while a 75% does something else).
That would not be possible.
Mach3 can generate a variable PWM signal (based on the S word in the Gcode) which could then be sent via the Parallel Port to the Gecko G540.
We're building a machine that needs an input to the computer to tell it to either reverse feed, continue forward, or stay stationary
Sounds like an ideal job for Mach3 or Mach4 but we would need some more detail of what you are intending to achieve.
Tweakie.
-
If you convert the PWM signal to an analog voltage, there are motion controllers that can accept analog inputs.
UC300ETH and CS Labs controllers have analog inputs.
-
Hi,
I assume that you are using a parallel port into which you have your G540 plugged in?
The G540 and parallel port is a great combination and is very simple. It has some limitations, particularly it has very
few inputs. This is fixed by the parallel port itself.
If you had a second port on a PCI card you will have more inputs. You could, and I would recommend, that you set Mach
to treat the second port pins 2-9 as inputs. The second port would then give another 13 inputs and 4 outputs.
You could then use several inputs to signal Mach and with a Brain (ladder logic code) Mach could determine what is required
from the several different options, ie de-code the inputs.
You would require a PCI card with a parallel port. Beware that not all, in fact not many work. I know PMDX sell a card which
has proven to work. You would also need a simple parallel port BOB, and it would need to be bidirectional, a C10 at $23.00
would be a cheap solution.
Craig
-
Hi,
https://www.pmdx.com/1PARPCI (https://www.pmdx.com/1PARPCI)
Craig
-
Wow, I'm amazed at the amount of support here. Thanks everyone!
In response to Tweakie's ask for more detail, we're running a sinker EDM machine with a microcontroller that acts as a voltage sensor. If the capacitor voltage drops too low, the controller tells Mach3 to reverse feed to avoid shorting out, and if it goes too high, it tells it to feed normally. If the voltage is in the middle, the sinker just sits stationary. All the voltage analysis is done on the microcontroller, so the problem is just how we communicate those three different states from the microcontroller to Mach3. Since you said you can't PWM the limit switch pin on the G540, I think that means this isn't possible with only one pin.
In response to ger21, that seems like a good idea. Do you mean that I could get a separate controller (I assume those boards replace a smoothstepper or something similar) and use the controller's pins? I assume I'd need some kind of breakout board to make use of the extra inputs safely.
In response to joeaverage, are you saying I could just plug in another PCIE parallel card, plug in a breakout board, and use that for a ton more inputs? I know I'd still need to process the input (it'll probably just be binary to decimal), and I was planning to use Brains, but other than that is the config as simple as defining the new inputs appropriately in Mach3? In that case, this seems like it'd give us a ton more input options.
Another thing though, I just saw something online about how you can put multiple limit switches on one pin. That would free up an extra pin, and then (with two pins) I could have up to four states, which would be fine. Would you all recommend putting multiple switches on one pin? It seems very simple but I know I may be missing something.
-
Hi,
Another thing though, I just saw something online about how you can put multiple limit switches on one pin. That would free up an extra pin, and then (with two pins) I could have up to four states, which would be fine. Would you all recommend putting multiple switches on one pin? It seems very simple but I know I may be missing something.
I have always argued against linking all the switches to one, or a few pins. I'm a lone voice against this practice however.
Many people do it just exactly to free up another input for some other purpose. My concern is that when you link all your
limits and home switches to one pin then Mach loses the ability to distinguish between a limit event or a home event and cant
even distinguish which axis.
If however you use a second parallel port card now you could have one pin for each home switch, one pin for each limit switch,
a total of 9 input pins and still have inputs to spare.
If you were to use an Ethernet SmoothStepper (ESS) you could have up to 51 inputs and outputs, with a maximum of 31 inputs.
Is that enough? If not consider a UC300, now you have up to 85 inputs and outputs, which if I'm not mistaken, means you
can have up to 57 inputs.
As interesting as that is.....there maybe a solution for your EDM sinker problem.
With Plasma Tables a very important control strategy is THC (torch height control). If the torch height is too high the voltage
of the plasma arc increases beyond optimum. A voltage measuring device (THC unit) would signal Mach 'Torch Down' and
Mach will lower the torch. This is usually done in realtime such that the torch voltage is controlled in a feedback loop.
You might be able to use the same strategy for your EDM machine. If you have a microcontroller that determines whether
the die needs to go up it could signal Mach to do so using THC_UP and THC_DOWN signals. If you do not have a up/down,
ie binary signal, you could make it by having a comparator and a reference voltage, a simple electronic circuit. It would
produce a signal up or down (binary).
I presume that you need the die to retract very quickly after detecting an impending short circuit event? If you need response
in the sub millisecond range then you must have a realtime controller. While not without its shortcomings Machs parallel port
is such a realtime controller and can support THC. Most of the external controllers like the ESS or UC300 also support
THC in Mach3.
Recently Mach4 has a script based THC feature added. It is done in software and is an order of magnitude slower than a realtime
THC solution, we anticipate in the range of several milliseconds. The advantage of that solution is that you can script your own
solution with all the processing power that Mach can bring to bear. The only question is.....'will millisecond response be
adequate to prevent my sinker die from shorting out?'
At the current time there are only two controllers that support realtime (read fast) THC support in Mach4, including the ESS.
Effectively Mach4 requires an external controller like the ESS. Mach4 does have a parallel port called Darwin ($25 licence fee applies)
but it does NOT nor will ever have realtime THC support.
The upshot is that if you wish to go for a Mach4 solution and thereby take advantage of the superior scripting flexibility that it brings
then you would require not only the purchase of Mach4 ($200) but an ESS ($190) also. I would guess therefore that you would
wish to stick with Mach3 and avoid the cost. I think you could use some workarounds to get Mach3 to perform as you wish
but you will have to code in VB, and good luck to you. There are plenty of VB masters on the forum but I'm not one of them.
In fact it was to avoid VB that I moved to Mach4 in the first place. If you want to do a Mach4 solution I'll back you but I'm
not going to 'bust a gut' over Mach3.
Craig
-
My concern is that when you link all your limits and home switches to one pin then Mach loses the ability to distinguish between a limit event or a home event and cant
even distinguish which axis.
From what I've read, Mach3 can home each axis in sequence so that it knows which one is homing when. I know that would be slower, but other than that is there another reason why it's worse? Also, should I have separate home switches and limit switches? The machines I've used, for example, on the x-axis, have one switch that homes and limits on the left and another switch that homes and limits on the right, and all of those are hooked to one pin. Admittedly each axis still has its own pin. I think this is how the G540 expects you to set it up too since it only has one pin per axis.
If you were to use an Ethernet SmoothStepper (ESS) you could have up to 51 inputs and outputs, with a maximum of 31 inputs. Is that enough? If not consider a UC300, now you have up to 85 inputs and outputs, which if I'm not mistaken, means you can have up to 57 inputs.
This sounds great. We were considering a SmoothStepper anyway, so this sounds like this is an easy way to go. I assume I'd still want optical isolation (or a breakout board with the same) on those extra inputs? Either way this sounds like a solution.
As to what you said about THC, I like that even better, but from what I've read THC only tells one axis (presumably the Z axis) to move up/down. I'm concerned that if I wanted to do more complex cuts it wouldn't work right; if, say, I had a sinker that was angled or flanged. Also, does that mean that the sinker would always be moving, since THC only has up and down? I also wonder if the sinker might plunge too far if it somehow bored all the way through; then it'd never have the signal to stop because the capacitor voltage would stay high. What part of the THC system prevents that? Of course, if THC allows more complex control, that would solve this all. I still feel like the best solution would be to forward/reverse feed.
Also, can I still get the few-millisecond (longer) response time you mentioned out of a Mach3 Brain? I'd guess a few milliseconds will be fine for this. I've actually found VB code that does this online, so I shouldn't need you (or anyone else) to bust their guts.
-
if you want to go the "VB script" road, you have to remember that there is only one Task (script) witch is running continious
(macropump). and this macro has a 10ms timestamp (theoreticly).
Brains are a lot faster but there Comes the external Controller into the Focus.
i never had something else than CSLab Controllers, but with them the update of Inputs takes 10ms as well.
-
Hi,
From what I've read, Mach3 can home each axis in sequence so that it knows which one is homing when. I know that would be slower, but other than that is there another reason why it's worse?
Yes, by all means it will work. As I stated I am a lone voice is this matter. When you crash your machine because Mach can't
distinguish between an X axis X++ event from a Z axis Z-- this conversation will come to mind....'I bloody told you so'.
I assume I'd still want optical isolation (or a breakout board with the same) on those extra inputs?
I use Homan Designs MB2 bi-directional breakout boards which don't have optical isolation. I have been using them for over five
years and have had no issues due to the lack of isolation. Electronics is my thing, so if I determine a situation where I suspect
that optical isolation is required then I make it to suit. What I do not do is demand that all inputs have optical isolation.
That would make bi-directional boards impractical. If you are of the opinion that optical isolation is mandatory then be prepared
to pay for the breakout boards that can do it.
THC only tells one axis (presumably the Z axis) to move up/down. I'm concerned that if I wanted to do more complex cuts it wouldn't work right; if, say, I had a sinker that was angled or flanged.
That is correct. You are adapting a realtime, that is to say an 'on board' feature over which you have no (software) control, to do a job
for which it was not intended. There will be limitations and incompatibilities. Whether you can live with them or mitigate them
remains to be seen.
You could of course go to a Gallil motion controller. That is programmable at board level, it is the gold standard among motion
controllers. Expect to start at $2000 for a three axis controller. You want good....you can have it, you just have to pay up!!.
Also, does that mean that the sinker would always be moving, since THC only has up and down?
In short yes, but when at optimum voltage it will move one step up, say 1um, then one step down, say 1um. In such a manner
it is quasi stationary. I think you will find most controllers, each of which enacts THC in their own way, have a 'voltage window'
such that if the actual voltage is within the target range THC_UP and THC_DOWN signals are suspended.
I also wonder if the sinker might plunge too far if it somehow bored all the way through; then it'd never have the signal to stop because the capacitor voltage would stay high. What part of the THC system prevents that?
Most THC plugins have some means of anti-dive control. For instance if a plasma cuts over a previously cut track its voltage
will spike high which in turn causes the THC unit to cause the torch to dive low. This is undesireable and much like the
break through event you have described. Most controllers offer some variation of anti-dive control. The sophistication and performance
of the anti-dive strategies offer insight into which control is better suited than another.
I still feel like the best solution would be to forward/reverse feed.
Yes I can well imagine that would be the best solution. That largely precludes THC as viable solution for a die sinker.
As TPS has pointed out that Mach3 has a defined macropump rate which would determine that a software defined feedback
loop would be very slow with a closed loop bandwidth of 5Hz or less. This I suspect would be too slow for a die sinker.
Mach4 however has a much faster, and within limits programmable PLC rate, which would allow for a software enacted feedback
control loop with a bandwidth of 20 maybe as high as 50Hz. Certainly the Mach4 THC module which I described is intended
as a software only solution for THC, so NFS believe that it has sufficient bandwidth.
If you were going to do a software solution that would accommodate things like angle cuts, flanged cuts and a mechanism to
prevent break through then Mach4 is by far the better platform to code it. TPS is one of the VB masters to whom I have
previously referred. If he is of the opinion that it can be done with VB and Mach3 then I'm sure it could be. If however he
is doubtful then I wouldn't go there.
Brains, also called PMC in Mach4 are fast but still far from realtime. To whit.....no-one has ever been able to write a Mach3
Brain that has successfully enacted THC, its just too slow.
NFS has however released the first and only software enacted THC control loop in Mach4. You make the decision.
Craig
-
Brains are a lot faster but there Comes the external Controller into the Focus.
Thanks TPS; it sounds like VB is out because of the speed limitation you noted, since I doubt I'd want to introduce a full 10ms of lag. Additionally, I just read on the SmoothStepper FAQ (https://warp9td.com/index.php/faq/faq-mach3 (https://warp9td.com/index.php/faq/faq-mach3) under "In ESS config, what does the Controller Frequency do") that the SmoothStepper's fastest buffer rate is 1/4 second.
I use Homan Designs MB2 bi-directional breakout boards which don't have optical isolation. I have been using them for over five
years and have had no issues due to the lack of isolation...
That's great to hear. I was, in a way, wondering why I should optically isolate if I can just connect the ground lines of my voltage microcontroller and the smooth stepper.
That is correct. You are adapting a realtime, that is to say an 'on board' feature over which you have no (software) control, to do a job
for which it was not intended. There will be limitations and incompatibilities. Whether you can live with them or mitigate them
remains to be seen.
I see. I think I misunderstood exactly how much of a difference in speed exists between THC and other solutions, and I'll plan to use THC. I guess my final question, then, is, is there any possibility Brains will run noticeably faster? If so, how much faster? Or will it all be limited by the smooth stepper's buffer lag?
-
Hi,
you have a few misconceptions going on.
it sounds like VB is out because of the speed limitation you noted, since I doubt I'd want to introduce a full 10ms of lag
This 10ms lag is not because VB is slow, but rather is the time taken by the controller to compose a data packet and transmit
it to Mach.
Secondly Mach3 has a macropump which cycles every 10ms. Thus if you have a macro in Mach3 that you wish to run continuously
it will run every 10ms. Mach4 has a similar idea called the PLC script. As default it runs every 50ms, but you can program it
to run more frequently. I have heard that some people have run it a 2ms intervals without causing the rest of Mach to crash.
In ESS config, what does the Controller Frequency do") that the SmoothStepper's fastest buffer rate is 1/4 second.
Windows PCs are not realtime machines, the way Windows uses CPU interrupts for its own purposes precludes Windows from
ever being realtime. CNC however is by definition a realtime operation. Mach gets CPU service in little chunks. To have a
Windows PC run a CNC machine means that Mach must generate a series of moves called PVT (position velocity over time)
in 1 ms slices. These are bufferd by the motion controller. ALL motion controller must do this. Even the parallel port
has a buffer.
What the buffer is doing is 'smoothing it out'. Mach might get CPU service from the Windows scheduler for 1.8ms. During that time
Mach might calculate 150 PVT data packets, enough moves for 150ms. They are transmitted to the controller buffer.
The Windows scheduler will then take CPU service away from Mach to do whatever else Windows decides needs doing.
Provided Windows get all those other jobs done or advanced a little and gives CPU service to Mach BEFORE the 150ms worth of
moves has been consumed all is well. If not the motion controller runs out of data and the machine stalls. Even if shortly
thereafter more PVT data becomes available its too late. Mach cannot accelerate to speed instantly. So when the controller
runs out of data the machine stops irrevocably.
I have never used the ESS on Mach3, only ever Mach4. I imagine there are differences but the same principle applies.
In the ESS Mach4 plugin the default buffer is 180ms. You can program it to be more, up to a maximum of 500ms, or less.
If there is a bottom limit I don't know it. The choices are to reduce the buffer length so that the PVT data from Mach is enacted
as soon as may be but then you risk the buffer running out of data. I have left it at 180 ms and have never had 'run out of data'
events.
The 'Controller Frequency' is the rate which the controller runs its internal loop. The ESS in Mach4 default is 40Hz, or 25ms. You can
program it to be faster but it demands comm service from the PC, thus an underpowered PC or one loaded down with extraneous
software and services may not keep up.
ALL motion controllers have this idea. The controllers, being hardware devices, could probably run very VERY much faster
but the PC couldn't keep up. So the 'controller frequency' is determined by PC not so much the controller.
With the comm delays, the controller frequency and the buffer using Mach to enact a feedback loop is to slow.
Having said that NFS have just released a software defined THC module for Mach4. Clearly NFS are convinced that it
can run fast enough to provide a useful solution. It may well be fast enough for a die sinker as well. If indeed it
is fast enough then you can bring all the calculating/processing power that Mach and a PC can bring to bear. That would
allow you to tailor the machine response to your machine, highly desireable.
If you determine that you need faster response then you must rely on the function built into the on-board firmware/hardware
provide by the manufacturer of the controller. Each manufacturer does it their own way and they won't share it with you,
its proprietary. Even if you had access to the manufacturers firmware how would you alter it?
There are some controllers like the Hicon, the PoKeys 57CNC and of course Galill that expose an on-board API to users that
they may form there own realtime functions. As I commented earlier Gallil is the absolute past master at this but is very
expensive. Just what the capabilities of the Hicon and 57CNC are in this regard I don't know. There is little or no discussion
on the forum about users exploiting the API.
Your choices are:
1) try to use THC as enacted by Machs parallel port
2) buy an external controller like an ESS and use the THC function provided as best you may, which may (or may not!)
be more advanced/flexible than the parallel port
3) buy a Gallil or other controller (Hicon or 57CNC) that exposes an API and write your own realtime function. This may require
some serious programming expertise. Researching what is achievable (both the hardware and your skills) BEFORE you buy
is required.
4) use Mach4, either the THC module as is or as a template for your own scripted function. This option exists only if
you can secure the closed loop speed to be effective.
Brains (Mach3) run very fast but they still do nothing about communication delays or buffering so they won't
save you. If they were fast enough would not a Mach3 software defined THC function been developed? In short Mach3
is too slow for a software defined control loop for THC and by analogy, your die sinker.
Craig
-
Hi,
i think the fastest you can get in Mach3 is brain in combination with a parallel port.
you can do a simple test.
download/install Mach3
assign Outpu1 to a pp pin
write a small brain, witch inverts the Output every cycle
take a oszilloscope and measure the frequency
than you will see the fastest possible reaction