Hello Guest it is November 18, 2019, 11:00:37 AM

Author Topic: Send PWM signal from Geckodrive G540 to PC  (Read 340 times)

0 Members and 1 Guest are viewing this topic.

Re: Send PWM signal from Geckodrive G540 to PC
« Reply #10 on: June 29, 2019, 06:01:33 PM »
Quote
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 under "In ESS config, what does the Controller Frequency do") that the SmoothStepper's fastest buffer rate is 1/4 second.

Quote
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.

Quote
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?
Re: Send PWM signal from Geckodrive G540 to PC
« Reply #11 on: June 29, 2019, 07:34:13 PM »
Hi,
you have a few misconceptions going on.

Quote
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.

Quote
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
My wife left with my best friend...
     and I miss him!

Offline TPS

*
  •  1,407 1,407
    • View Profile
Re: Send PWM signal from Geckodrive G540 to PC
« Reply #12 on: June 30, 2019, 01:21:21 PM »
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
anything is possible, just try it.
if you find some mistakes, in my bad bavarian english,they are yours.