Hello Guest it is March 28, 2024, 08:21:54 AM

Author Topic: Mach4 Spindle At Speed, Spindle Zero Problem  (Read 20813 times)

0 Members and 1 Guest are viewing this topic.

Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #50 on: October 19, 2017, 10:27:20 AM »
Hi Craig,

I changed the relay output with signal output and it does the same glitch.

I am controlling the VFD with 0-10V, PWM signal and i think u are right about the start signal and frequency signal but logically u adjust the vfd to turn that signal on when spindle is at commanded frequency not when start running, so i think there is a bug in vfd's logic also.

In m3 code it checks the input62 whether it is HIGH or LOW and if its HIGH it goes on to script, is it possible to put a time constraint to alter the momentary signal? for example is it possible to say if input62 is HIGH for lets say 2 seconds go on, if it is not for lets say 10 seconds feed hold the machine and display a message in window and ask user if he wants to go on or not with spindle off, because sometimes u may run the code without turning on the spindle to check if the code is ok for some reason..

if this is too complicated we can just feed hold the machine.

Regards,

Hakan
Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #51 on: October 19, 2017, 02:05:56 PM »
Hi,
the fault is your Gcode. It should set the PWM with a Snnnn command, wait for 5-10ms for the PWM to propagate to the VFD THEN issue a start command.

You can cheat to overcome this if you can't be bothered to fix your Gcode by having a delay before calling mcSignalWait so that the glitch has been and gone
before Mach requires it.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #52 on: October 19, 2017, 02:50:58 PM »
The fault is not necessarily with the G code. It is common to issue an M3 and an S word on
the same line of G code.

Even if the S word is issued in advance, that does not guarantee that the PWM to analog
conversion will happen before the M3 takes effect. That will be dependent on how the
motion device handles the signals. PMDX products will inhibit the analog out until the
M3 is issued. Indeed, Mach3's own parallel port driver will not generate a PWM signal
until the M3 or M4 command is issued.

Using a pause for spin up, or using feedback are valid approaches to the problem.



Steve Stallings
www.PMDX.com
Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #53 on: October 19, 2017, 03:43:25 PM »
Hi Steve,
kool thanks for that explanation. A simple delay will probably work. Thanks again.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #54 on: October 20, 2017, 11:20:21 AM »
Hi Craig,

I didn't fix the signal glitch problem from VFD but i changed the code as follows so it works for me like this;

Code: [Select]

function m3();
local inst=mc.mcGetInstance();
mc.mcSpindleSetDirection(inst,mc.MC_SPINDLE_FWD);
wx.wxSleep(1)
mc.mcCntlSetLastError(inst,"m3 waiting");
local returncode=mc.mcSignalWait(inst,mc.ISIG_INPUT62,mc.WAIT_MODE_HIGH,10);
    if (returncode==mc.MERROR_TIMED_OUT) then
        mc.mcSpindleSetDirection(inst,mc.MC_SPINDLE_OFF);
        mc.mcCntlSetLastError(inst,"spindle did not respond, cycle stop");
        mc.mcCntlCycleStop(inst, 0);
       
    else;
        mc.mcCntlSetLastError(inst,"m3 at speed");
    end;
end
if (mc.mcInEditor() == 1) then
    m3()
end


i am not sure if this "mc.mcCntlCycleStop(inst, 0);" is the correct usage of it but it works fine like this.

this code jumps over the glitch problem by waiting for a second or so before checking the input62 so when spindle reaches the commanded rpm vfd turns on the input62 and code says "m3 at speed" and goes on to gcode.

Also in case of missing input62 HIGH, it says "spindle did not respond, cycle stop" and stops the gcode.

Regards,

Hakan
Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #55 on: October 20, 2017, 03:02:55 PM »
Hi Hakan,
kool, that is very much what I had in mind for your machine.

Only a week or so ago you were convinced that you couldn't write or didn't want to write any Lua code now you're doing it on your own!

An alternative that you might wish to explore in the future is having another macro, m100 for instance, that when called does things like
record the name of the current G code file, the line number being executed.....and so on. All the features you might require in a shutdown script.
In the case of your m3, m4 or m5 scripts an unresponsive spindle might qualify as a shutdown event. If that were the case you'd substitute

mc.mcCntlGcodeExecuteWait(inst,'m100') for your current shutdown statement mc.mcCntlCycleStop(inst, 0).

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #56 on: October 20, 2017, 03:36:55 PM »
Hi Hakan,
the Lua syntax:
Code: [Select]
rc = mc.mcCntlCycleStop(
number mInst)

So you don't need the extra  ",0 in the cycle stop API. I doesn't hurt it though, Lua matches arguments one for one and leaves the rest. So the "0" input
argument would be ignored.
Mach4s API help docs are in the <Help Docs> library of the File Ops tab. I use it that much that its now pretty much permanently on the task bar.

Craig.
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #57 on: October 20, 2017, 05:50:57 PM »
Hi Craig,

"Only a week or so ago you were convinced that you couldn't write or didn't want to write any Lua code now you're doing it on your own!"

Come on, u wrote the code i just added 2 lines in there and i took one from Daz's code ;)

I want to learn Lua and write scripts with it to program Mach4 also want to make the interface with it which has animated readouts etc. but Lua has very limited resources on the web. For example as a programmer those resources may be enough for you but for people like me it has to be more like the arduino resources, it has to be more detailed with much examples.

But the thing that u and Daz do in here, helping people for beginning in Lua is something very valuable, i really appreciate your help, thanks once again.

Today when i made the code work, i enjoyed watching the machine act more aware of whats happening, u know it listens an input, waits and when spindle gets to desired rpm it moves the machine, it acts more smart. Machines should not move blind or operator dependent, they can be more reliable with these kind of small add-ons.

M100 idea is a very good idea, it will be wise to make it write the all collected data to a file and make arduino keep the file or load it to restart sequence of the controller after the AC line restored..

Regards,

Hakan




Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #58 on: October 20, 2017, 06:29:18 PM »
Hi Hakan,
I felt exactly the same way only a few months ago, I thought I had made a big mistake trying to learn Lua. You're right there doesn't seem to be that much useful
stuff about Lua. There is in fact enuf about Lua, Lua is in itself very simple, where it gets tricky is adding API calls, wxWidget calls and Machs software structure.
In that regard there is no substitute for rolling up your sleeves and getting stuck in. That's what I did and with the help of Daz and smurph I have made progress.
Progress is very satisfying as you've found. Despite your beginner status you've already surpassed the efforts of many.

As I commented before helping someone else code something new is a perfect opportunity for me to learn new things about Lua.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Mach4 Spindle At Speed, Spindle Zero Problem
« Reply #59 on: October 21, 2017, 04:10:51 PM »
Hi Hakan,
I had a reply from Rob at Artsoft about the input signal snafu I blundered into. He confirms that we would require an expansion board to use ISIG_SPINDLE_AT_SPEED.
This poses another question. Certainly we know that ISIG_SPINDLE_AT_SPEED is defined and it works, we can see the LED turn on and off. We wished to
make use of it in our mc.SignalWait() API call but it didn't work there and Rob confirms that some expansion would be required for it to work.

I'm guessing here, but based on a few related observations ALL of Machs input are numbered 1 thru to whatever. Internally Mach has no idea what ISIG_INPUT#17
or ISIG_SPINDLE_AT_SPEED means, it recognises input #17 and input #181. So the labels are defined for our benefit because we don't immediately recognise
input #181 for instance. It would appear however that not all API calls are created equal, in this case mc.SignalWait will accept inputs 1-64 but not higher
but mc.SignalGetHandle() will tolerate an input higher than 64, our #181 being the numeric equivalent to ISIG_SPINDLE_AT_SPEED for example.

What is not clear to me is what sort of 'expansion' is required. Given that input #181 can be read and interpreted by Mach in some instances suggests there
are enuf bits for several hundred inputs so it won't require a hardware expansion. I can only guess that mcSignalWait requires software extension.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'