Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: hekav on May 06, 2018, 08:26:49 AM
-
Hello,
I have a Hitachi VFD connected via modbus to Mach4, and almost everything works as it should.
The VFD has two coils Mach4 spindel_at_speed and spindle_at_zero.
I can see them in the modbus monitor. But when I connect the modbus coils to mach4 "Spindle At Speed" and
"Spindle At Zero" mach4 does not wait for the signals. Instead is starts immediately with the gcode moves.
Why can I connect the modbus coils to the input signal, if they doing nothing ?
Is this a bug or a feature ?
Helmut
-
Hi,
I was heavily involved in a conversation about exactly this matter some time ago:
http://www.machsupport.com/forum/index.php/topic,35694.0.html (http://www.machsupport.com/forum/index.php/topic,35694.0.html)
Craig
-
Hi Craig,
I have read that thread. But still, it make no sense to me to define the signal,"Spindle At Speed" and "Spindle At Zero" when you can't use it.
Like hakan said, it's a bug/or unfinished software.
BTW: I changed my m3,m4 and m5 like you suggested, and it works for now.
Helmut
-
Hi,
Like hakan said, it's a bug/or unfinished software.
Rubbish. The Signal is defined its Action is not....you the machine integrator have to decide what action is correct and code it accordingly. Mach4 IS NOT LIKE Mach3, its not
plug and play.
Craig
-
Hi,
Machs developers made available a sophisticated spindle index sensing suite including a very accurate speed measurement and live DRO reporting with delays until up to a percentage of
commanded speed. Is there a reason that you didn't use the facility that was provided?
Craig
-
Hi,
as I said earlier, my VFD is connected via modbus and I found now documentation how to do that with modbus.
Rubbish. The Signal is defined its Action is not....you the machine integrator have to decide what action is correct and code it accordingly. Mach4 IS NOT LIKE Mach3, its not
plug and play.
No Rubbish, At least mcSignalWait(..) is not working with the signals "Spindle At Speed" and "Spindle At Zero".
Remember I have a Mach4Hobby license and for a Hobby User I can expect some out of the box functionality.
I could live with the restrictions but there is also no documentation. Can you tell me where can I find this "The Signal is defined its Action is not...."
in the documentation.
Everything I have done so far was by trail and error or by looking in the forum. The documentation is for sure rubbish !!!
Helmut
-
Hi,
as previously explained the numeric range of signals for which mcSignalWait() will work is limited to 5bits ie 0-63. That is what it is.
I stumbled over it and you are right there is no notes or documentation covering it, I have asked NFS to add one line to the API.chm but to no avail.
For this reason I have commented before that NFS does not appear to act on specific documentation suggestions.
Remember I have a Mach4Hobby license and for a Hobby User I can expect some out of the box functionality.
Good luck with that! In this instance NFS is not to blame however, the modern programming paradigm is that an object and its action are separate and
Mach4 follow that paradigm. What Mach4 is very very good at is being programmatically flexible but that in turn requires that you program it to suit
your particular needs.
Everything I have done so far was by trail and error or by looking in the forum
I agree, I've had exactly the same experience.
The documentation is for sure rubbish
I would not put it that strongly but certainly the documentation is out of date. smurph has explained that generating technical documentation is a very
resource/time intensive excerise. NFS has not taken up that challenge yet, but have persued further development....things like PMC, the probing module, the Zero Brane
editor....all of these things are new. They would not exist if NFS poured its resources into documentation say.
Craig
-
Mach4 can run straight out of the box. Once you setup motion you can run it just fine. However, the beauty of Mach4, is being able to add your own little flare to the system.
Mach4 is improving day by day, I remember coming into work and for almost a week straight there was a new developmental version ready everyday. The time it would take to keep up to date documentation would be crazy.
I will say however, things that are nailed down like the PMC and Probing could have some nice updated documents to help end users.
Side note speaking of Zero Brane. Have you noticed an issue with Zero Brane "Find". It doesn't work at all on my end.
-
Hi,
Find works on my installation. Haven't tried all the combinations yet but finding variables no sweat.
Craig
-
Hi,
yeah, decided I like this Zero Brane editor. Still got quite a way to go to match the flexibility of debugger in a mainstream IDE, but its a good step in the right direction.
Helmut, you may not realize that Zero Brane is new, very new, maybe a month old or so. I understand your frustration that NFS has not done a lot of documentation or
given Mach4 a lot of pre-programmed solutions to things but they haven't been idle. This Zero Brane editor is a good step. Note that it makes programming and debugging easier,
it doesn't make Mach4 Plug'n'Play. It is a clear indication of where NFS is heading.
I hope you stick with Mach4 because once you become accustomed to the 'ethos' you will come to realize just how damn good it is! If you get in now it will develop around you whereas
if you try to pick it up in a couple of years time it will be OVERWHELMING, its quite enough of a shock as is!
Craig
-
I have just tested the at speed and at zero signals and they works perfectly.
There are multiple spindles waits.
1. Time based (setup in the spindle range tab)
2. RPM feedback based (spindle stabilization)
3. Signal based.
Pick one method. Not 2 or 3, but 1. :)
The stock (and default) default method is time based. It does not require anything but setting up the ramp times in the spindle tab. It does not require a m3.mcs script in the profile. 99% of the hobby users use this.
The signal based waiting also does NOT require a custom m3.mcs script. If you have a m3 script, it will override the default behavior of the Core and you will have to duplicate the default behavior.
For the signal based method.
1. Map and ENABLE the at speed signal. You have to map it to an I/O object. In this case, a coil from a modbus device. Enabling the signal mapping is important as it will NOT work if it is not enabled. That is how Mach know to look at the signal. Otherwise, it will use the time based wait. And if you have no times defined, the spindle will start instantly.
2. DO not check the spindle stabilization check box in the spindle settings. That is RPM feedback based. And because the VFD will hopefully tell us it is stabilized with the signal.
So I downloaded a nice little modbus simulator and configured it along with the modbus plugin configuration. I then mapped that modbus input to the spindle at speed input signal and enabled the signal. I can now control my spindle at speed signal at will with it and thus, my spindle start wait. http://www.plcsimulator.org/downloads
If you are having problems with the spindle immediately starting, I suspect that the signal is not enabled. Again, it has to be enabled and mapped. Once it is enabled and mapped, issuing a M3 should block until it times out. (approx 10 seconds). Or your m3 script is not doing the right thing. If you need a custom m3 script, have a look at the scripting manual. It has spartan example of one. It ALMOST duplicates the stock M3 behavior with the exception that it does NOT wait. Use mcSpindleSetDirectionWait() to enable waiting on the spindle.
Another thing you may need is the spindlespeed.mcs script. This is run every time a S word is issued. It is a handy way of setting a speed for a modbus controlled VFD.
There is a plethora of documentation in the Doc folder in the Mach installation directory. Scripting Manual, Mach4CoreAPI.chm, Operators Manual, G code manual, etc... They may not cover everything, but I feel like they are pretty decent. Try reading Fanuc manuals! The problem is, as with most anything like this, the only way to REALLY understand the system is to read every one of the manuals, cover to cover, and then read them all again. Sometimes several times! :)
And the manuals keep getting bigger. I just updated the G code manual with a whole lot of things for the newest development builds. 3784 is on the FTP site if any are interested.
Steve
-
Hi Steve,
your post is most informative.
I a while back was trying o help a bloke who wanted the Gcode file to pause until an AT_SPEED output on his VFD came good.
I used the mc.SignalWait() API. I had some bother with it until I discovered that the range of input signals for which it works is limited
from 0-63, ergo ISIG_SPINDLE_AT_SPEED being outside that range didn't work. I commented at the time that had even the shortest of
comments about the restriction in the API.chm document would have been most handy.
Once we had that matter in hand coding the rest was pretty straight forward.
Is there any formal process where users might post a specific addition or correction to the current documentation? There has been two posts in recent
months where this particular problem has cropped up for users. I was able to assist in both cases but it would have been easier still if the document had
a single line addition.
Craig
-
Hi
thanks Steve
this was the trick:
The signal based waiting also does NOT require a custom m3.mcs script. If you have a m3 script, it will override the default behavior of the Core and you will have to duplicate the default behavior.
I did not delete the m3.mcs, I just commented out all lines.
Helmut
-
Thanks Steve. Your posts are always most welcome and never fail to shine an unseen light.
A possible issue with the mcSpindleSetDirectionWait() call is that it gives no indication that it has timed out , so after 10 seconds or so the machine just continues on. Fine if that is what you want, but maybe you'd rather it stopped so you could resolve the cause. The default timeout may behave in the same way - I haven't tested it so I don't know.
Allan
-
Hi Allen,
no there was a test for 'timed out'. The rc was MERROR_INVALID_ARG.
Craig
-
Hi Allen,
and the API was mc.SignaWait()
Craig
-
Hi Craig
Just wondered where you got that info. It doesn't make much sense to me, as a bad argument is quite distinct from a timeout. When I tested the timeout condition returned error 0 (no error).
Allan
-
Hi Craig
We may be at cross purposes. I was referring to the call mcSpindleSetDirectionWait() mentioned by Steve above. SignaWait() gives the error MERROR_TIMED_OUT as you might logically expect.
Allan
-
Hi,
the API which is subject to the signal range restriction is mc.SignalWait(). If the input signal is not in the range ISIG_INPUT1 to ISIG_INPUT64 then you will get MERROR_INVALID_ARG.
Steve introduced mc.SpindleSetDirectionWait(), but that introduction to the conversation is recent.
Craig
-
Hi Craig
My comments applied only to Steve's suggestions. These do not have the 0-63 limit. Sorry if I muddled things.
Personally, I continue to use mcSignalWait() due to its more complete error handling.
Allan
-
Hi Allan,
if I understand Steve's suggestion has a fixed delay whereas the mc.SignalWait() solution delays
ONLY until a signal from the VFD comes good. That was the intent and desire of Hakan, the bloke
I was helping at the time. Current OP, Helmut, needs the same solution.
Both Helmut and Hakan were bemused, even annoyed, that ISIG_SPINDLE_AT_SPEED and ISIG_SPINDLE_AT_ZERO
have no action despite the signal being defined within Mach's core.
Secondly they were annoyed, with some justification, that the documentation lags the reality.
I confess some exasperation that a very simple one line addition to the API.chm which would rectify
the matter has been ignored.
Craig
-
If you are using the stock spindle wait, there is no return code because no m3 script exists. I did increase the wait timeout to 20 seconds because it may take longer than 10 seconds to bring a 20K RPM spindle up to speed.
If you are are using a m3 script, mcSpindleSetDirectionWait() will now return MERROR_TIMED OUT and the API docs reflect this. I juuuuuuust fixed this and it will be in the next build.
Also, the mcSignalWait() function will wait on ALL input signals instead of just the 64 general input signals for quite some time now. As it was always supposed to. So the docs do not mention a limitation, as there wasn't supposed to be one. The issue was that the function was incorrectly ignoring the rest of the inputs.
If you want more control over the spindle waits using signals, and don't want to wait up to 20 seconds for a timeout, then using the mcSignalWait() API function on ISIG_SPINDLE_AT_SPEED and AT_ZERO may be what you need.
I have been using the stock spindle wait with the signals on my personal machine since the beginning of Mach 4 time without issue. The reason those signals are there is because I WANTED them for my machine! :) I don't use any custom M3, M4, or M5 scripts. In fact, I don't think I have ANY custom scripts other than M6 to run the tool changer. The machine is a Matsuura MC500. I installed Mach 4, wired my VFD outputs to some inputs and mapped the "at speed" and "at zero" input signals, and enabled them. No drama at all. It was intuitive. I could run that very complex industrial machine (with all of the safety bells and whistles) with Mach 4 "out of the box" with no scripting required if I didn't want to use the tool changer.
So when people complain about Mach 4 being difficult because you HAVE learn LUA to program it, I just don't get it. If you THINK you need something custom, then either you have a Rube Goldberg device or something that just can't be shrink wrapped. Tool changers are pretty much the only thing that falls into this category. Otherwise, you may need to take a step back and think about if you have made a fundamental flaw in the retrofit or machine design. VFDs can get a bit more complicated if you are using modbus. But 99.9% of the hobby AND industrial milling machines really should not need much scripting at all. It is when you want something SPECIAL that scripting is needed.
Steve
-
HI Steve,
kool, as I say the mc.SignalWait() restriction tripped me up back then, sounds like that limitation has
been addressed, good stuff.
If you want more control over the spindle waits using signals, and don't want to wait up to 20 seconds for a timeout, then using the mcSignalWait() API function on ISIG_SPINDLE_AT_SPEED and AT_ZERO may be what you need.
Yes, that was the exact reason that Hakan wished to pursue that idea and we did get it to work.
Craig
-
Hi Steve,
almost all the custom code that has turned up in my installation has got there as a result of me
trying to help someone else do something specific rather than me needing, or even once I've
completed the code, actually using it.
I change tools manually and therefore have little need for M6's.
Some code I have written is actually more about file processing, I might run a Gcode file through
a Lua script to change or correct the code before commiting it to the machine. I have another script I have
written is for coil winding, pretty simple but effective.
The truth is that there is really nothing about my setup that requires custom code to run.
Craig
-
Excellent news Steve. Sounds like all should be good very soon.
Allan