Messages

2321

Mach4 General Discussion / Re: Having trouble with Probing

« on: July 06, 2019, 08:15:54 PM »

Hi,

Is there a plug-in I need to enable or disable, a file somewhere that isn’t automatically updated with an updated install?

No, I don't think so.

Notwithstanding your efforts to immunize you machine from noise I still suspect that it is happening.

May I suggest a simple experiment. If you write a small script, or easier still just a couple of lines in the MDI panel
and you can probe. What this means is that the software of the TouchOff module is not involved at all. If there remains
a problem then its more hardware. If there are no probing problems  encountered then its the software of the module.

Jog the machine to above, 1/4 inch or so above a surface to be probed. Zero the z axis. Code into the MDI panel
g31 z-1 f10
g0 z0

If you execute I would expect the probe to descend at 10 inch/min until probe strike. Thereafter it should return to the same
height (ie 1/4 inch approx.) that you started. If the machine cannot do this repeatedly and consistently then no amount
of software in the probing module is going to help.

Craig

2322

Mach4 General Discussion / Re: touch probe function question

« on: July 06, 2019, 07:26:55 PM »

Hi,
its in the Mach4Hobby/modules directory called mcTouchOff.lua, all 292k of it. Enjoy!

Craig

2323

Mach4 General Discussion / Re: Having trouble with Probing

« on: July 06, 2019, 06:01:19 PM »

Hi,
I use the probing module a lot without problem.

sometimes when I try to do a simple Z probe the Z axis goes Up instead of down, and not even by the amount I have it set to go down by.

One possibility to consider is noise on your probe signal line. When you manually touch the probe none of the motors are running.
When you are probing they are running and could be producing a spike which is recognized by Mach as a probe event.
Try in the Pins Config of the ESS plugin introducing some noise filtering, a value of 100 is a fair place to start. A 0.1uF capacitor
on the probe input of your breakout board is another simple experiment along the same lines.

Trying to probe an X/Y corner, using the default 0.25" setting will send the probe off along the Y axis until I force it to stop

The only thing I can suggest is that the probing module assumes that your machine follows the right hand rule with regard to
axis directions. If your machine is not configured that way then you would have the trouble you have described. Ther is
a video by NFS that shows the right hand rule, I will try to find it and link it to you.

Craig

2324

Mach4 General Discussion / Re: touch probe function question

« on: July 06, 2019, 05:38:18 PM »

Hi,

If I understand you correctly, there is no mechanism to do the same in Mach 4 without modifying the code.  Is that correct?

In the strictest sense that is correct. The probing 'move' is g31. It does not back off. It behaves the same in Mach4 as in Mach3.
In order to probe materials requires a short sequence of moves, a g31 to move to and probe the surface and then another
move to back off.

You can if you wish code these yourself but you don't have to, there are many 'scripts' where the code is already written.

The Touch module in Mach4 is a great example, and much improved over any of the Mach3 probing routines.

Craig

2325

General Mach Discussion / Re: Mach3 and Mach4 on same computer with Pokeys57cnc

« on: July 06, 2019, 05:26:42 PM »

Hi,
they operate so similarly that it doesn't matter.

Yes you can operate Mach3 and Mach4 on the same PC with the same motion controller, a 57CNC for example.

Craig

2326

Galil / Re: Galil controller compatability (what works with the plugin)

« on: July 06, 2019, 03:06:33 PM »

Hi,

The need is to use a bipolar + & - 10v analog signal from two Mach4 DRO axes to tell the servos to move.

Why do you need analogue voltages?

Most modern servos can still be driven by an analogue voltage but that requires a feedback capable motion controller.
In this setup the encoder is still hooked to the servo drive, as I explained earlier the encoder is required by the drive
to compose it output. The encoder, or some derived signal from it, is outputted to the controller. The controller
closes the loop. The controller outputs a precision analogue voltage and the servo turns at a speed determined by the
voltage. The servo is in velocity mode.

The same servo could be in position mode. In this set up the position is commanded by Mach4/Galill as a series of
step/direction pulses. The servo drive accumulates those pulses and therefore knows where is it supposed to be.
It compares where it supposed to be to where it actually is (by the encoder) and drives the servo accordingly.
The PID tuning is done entirely within the servo drive. The controller has no need of the encoder signal at all.

If  Mach4 decides that it needs to drive an axis 100mm in the +direction it will plan the trajectory as a series of
P(osition)V(elocity)over T(ime) data packets in 1 ms slices. The motion controller will convert the PVT data to step/direction
pluses for all servos.

At the beginning of the move Mach will plan to accelerate the axis smoothly before reaching it ultimate speed. The servo
and drive are assumed to be capable of the acceleration and ultimate speed required. If the servo can't keep up with the
planned trajectory then the drive will fault 'following error'.

In this way Mach4/Gallil are an open loop controller only. It provides the trajectory which is converted to step direction pulses
and the servo just goes there. If it can't it will signal that with a following error fault. This is a more modern control setup. It means
that the motion controller does not have to be feedback capable. The only feedback capable controllers that work with Mach4
(Gallil, Hicon Integra, CSMIO/A) are all expensive, the cheapest is 600Euro. By comparison the plain open loop step/direction
motion controllers (Ethernet SmoothStepper, UC300, UC00, UC100,57CNC, 57CNCdb25,PMDX-411, PMDX-242) range from
$120 to $250.

The Ethercat solution which is being developed for Mach4 requires two pieces of software for your PC only. RTX64 by
Interval Zero provides a realtime core capability to your non-realtime Windows PC and KingStar provide the plugin
that makes Mach4 an Ethercat Master. The servo drives (all Ethercat slaves) are connected by a daisy chain of Ethernet
cables.......and that's it. No expensive hardware controller required!

You may have noticed that you can hook limit switches to your drive, you don't have to hook them to the controller at all.
The servo drive is smart enough to handle that. It is in fact a required feature that any servo drive must be able to do
if it is ever to be Ethercat slave capable. That is to say that the servo can act autonomously.

Craig

2327

Galil / Re: Galil controller compatability (what works with the plugin)

« on: July 06, 2019, 05:57:38 AM »

Hi,

but with these Kollmorgen AKM servos, can they work properly without the encoder signals connecting back to the S200 drivers?

I'm not familiar with Kollmorgen servos, my experience is with Allen Bradley servos. I suspect that the servos would not, in fact
could not operate without the encoders connected and working.

Leave aside for the moment that how would the drive know when to commutate the stator windings but without the encoder the
drive has no means to determine the rotor position so it cannot then calculate the phase currents necessary to produce
a stator field in phase quadrature to the rotor and produce torque thereby.

It is absolutely fundamental to Field Oriented Control AC servos that the rotor position is known to the drive, be it an encoder
or a resolver. Without rotor position there can be no quadrature stator field. Texas Instruments do a truly excellent
video on Field Oriented Control.

https://www.youtube.com/watch?v=cdiZUszYLiA

Modern servos ABSOLUTELY require a matching drive. As such the motion controller can just be open loop step/direction,
it need not be a feedback controller. The servo and servo drive manufacturer does a superb job of matching the servo
and drive feedback loop. In all fairness they do a better job of it than you or I can do and exceed the capabilities of even
top motion controllers like Gallil.

My Allen Bradley servo for instance has thermal parameters such that the drive can model the thermal performance of the
servo. Even more amazingly the servo has piecewise linear magnetic coefficients so the drive can model magnetic saturation
effects which incidentally feed into the thermal model. Such sophistication of thermal and magnetic modeling is
just that much more advanced than any motion controller.

The trend in CNC is that servo and servo drives are getting smarter and smarter.

Once upon a time servo drives were just amplifiers. The motion controller monitored the encoder/resolver; enacted the
feedback loop and outputted a precision analogue voltage to the servo amplifier. The servo drive was dumb, or maybe had
a velocity feedback loop at best.

More recently servo drive itself monitors the encoder/resolver, enacts the feedback loop and drives the servo directly. The motion
controller need only be open loop step/direction type. Think Mach3 and Mach4. The servo drive now has all the feedback
tuning including the thermal and magnetic modeling I've already mentioned. The servo drive is smart.

More recently still with Ethercat, Profinet, CANOpen and others the servo drives are becoming motion controllers in their
own right. Thus you don't have a motion controller at all, your PC becomes the trajectory planner and is the
Ethercat master while each of the Ethercat slaves (each servo drive) does it own motion control. This is called 'distributed
motion control'. It IS THE COMING THING. The servo drive is now smarter than the controller!

When you log onto the Mach forum you may have noticed a video of a Matsura VMC doing a job. What you may not have noticed is
the Mach4 is the trajectory planner with KingStar/Interval Zero RTX64 providing the software to make Mach4 and the PC
an Ethercat master. So that Matsura is running WITHOUT A MOTION CONTROLLER!!!

The days of sophisticated feedback controllers like Hicon and Galill are numbered, why would you bother with expensive
realtime hardware when you just need a little extra software and some Ethercat capable servos?

As I said, the trend is for servo drives to get smarter and smarter......what happens next???

Craig

2328

General Mach Discussion / Re: Mach3 and Mach4 on same computer with Pokeys57cnc

« on: July 06, 2019, 05:08:01 AM »

Hi,
I thought it would be a good idea to run Mach3 and Mach4 on the same PC with my Ethernet SmoothStepper.
What actually happened is once I started using Mach4 and realized how much leaner and cleaner it was I've never used
Mach3 since. So much so that when I accidentally lost my Mach3 lic.dat file I didn't bother trying to replace it.

Craig

2329

Mach4 General Discussion / Mill Profile Initialisation String

« on: July 05, 2019, 09:13:14 PM »

Hi All,
I am struggling to find the code that results in the initialization string that occurs in my mill profile.

In particular I wish to delete the G54 from the list. I have scanned through the machine.ini file and not found anything
that appears to be the init. string.

I am aware that I can provide my own init. string in Machs Control plugin but I still want to delete the G54. The correct
work coordinate set will provided by a script and may well vary between sessions. Therefore a fixed initialization string
as the one in the Control plugin is not suitable.

Craig

2330

Mach4 General Discussion / Re: PMC Help

« on: July 05, 2019, 09:00:35 PM »

Hi,
I think that you would have more success if you looked at the spindle API instructions.

You have changed the state of a signal (OSIG_SPINDLEFWD) which presumably is hooked to your spindle driver
and I would expect it to turn the spindle on. Does not 'spindle forward' imply that the spindle must also be turned on?
I suspect that Machs internal logic may be counteracting your intention.

May I suggest that you experiment with output signals 0 through 5; you can be assured that some internal logic is not
interfering with your desired sequence of operations. Secondly using those particular out siganals mean that the six LEDs
on the MachineDiagnostics tab display the signal current state.

It may well be that as a result of your experimentation you can shift the output signals to say #20-#22 say; leaving
#0-#5 free for 'playing with' later on. Or better still you may be able to unravel how Mach uses and interprets the
OSIG_SPINDLEFWD, OSIG_SPINDLEREV and OSIG_SINDLEON signals.

What you want is to set the spindle direction, a flag or variable, without also turning the spindle on. These APIs may help.

Code: [Select]

rc = mc.mcSpindleSetDirection(
number mInst,
number dir)

Description:
Set the desired spindle direction.

rc = mc.mcSpindleSetDirectionWait(
number mInst,
number dir)

Description:
Set the desired spindle direction and wait for the spindle to come to speed. The function will wait for up to 20 seconds before returning MERROR_TIMED_OUT.

The type of spindle wait is determined by the system configuration.

I confess that I don't know whether these will achieve the result you want. Does for instance setting the direction flag ALSO
cause the spindle to start? Some experimentation is in order.

No matter the result of the experimentation and whether a particular API works or not you need a logical set of steps.
I envisaged a logical structure something like this:
m3
1) if the spindle is stopped then turn it on CW.
2) if the spindle is on and in CW rotation....ignore m3
3) if the spindle is on and in CCW rotation......stop the spindle.....delay....start the spindle CW

m4
1) if the spindle is stopped then turn it on CCW.
2) if the spindle is on and in CCW rotation....ignore m4
3) if the spindle is on and in CW rotation......stop the spindle.....delay....start the spindle CCW

m5
1) if spindle is on....turn it off....delay before resuming operation
2) if spindle is stopped....ignore m5

If this looks reasonable to you THEN you can start looking at various APIs, macros, PMC scripts or whatever to enact
the desired scheme.

Also I couldn't find a good way to put a delay in, didn't want to use the wx, call..

Why not?

Craig