Hello Guest it is March 29, 2024, 07:26:35 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - smurph

611
M19 is usually used for spindle orientation.  It is an interface script that should eventually call the "spindleorient.mcs" script.  You only need to find the index pulse once (home the spindle, so to speak).  Then you can mathematically calculate where it is by the number of counts per rev on the encoder, assuming the encoder is 1:1 with the spindle shaft (highly suggested).    Rollover may be an issue.  Use and encoder with the lowest resolution needed to get the job done to keep rollovers at bay.  Just re-home if you detect a rollover.  However, most M19s will spin at a certain speed and find the index pulse every time and then index from there. 

We don't define the arguments to M19, as there are so many variations from the MTBs.  So Brett has just done up and example M19 that can be used as a starting point.  I might be in the newest builds.  It uses R and P arguments to the M19 script.  R is the angle to orient in degrees and P is the direction to orient (0 == shortest path, 1 == clockwise, 2 == counter clockwise).

Steve

612
Mach4 General Discussion / Re: A Aixs Brake
« on: May 10, 2018, 10:42:24 PM »
It is usually called a clamp if it is pneumatic.  And since they are pneumatic and cause a delay, most of the time they are engaged/disengaged with M codes.  A lot of MTBs (Machine Tool Builders) use M10 and M11 for the 4th axis clamp.  M11 and M12 for the 5th axis clamp.  But they are really all over the map with not much of a standard.  An electric motor brake can usually be driven with an output on the drive because it is fast acting.  

To do the 100ms wait, that would really have to be a function of a motion plugin to detect the motion on the A before it was actually executed.  The motion plugin could simply wait 100ms (or more or less) or wait on an output, etc...  before executing the motion.  Pretty custom.  Or you could simply let the A axis handle a lot of following error and let it catch up?  

Steve

613
Yes.  As long as you keep things from getting split brained. 

Steve

614
Out of band axes are for controlling things like chip conveyors, stock feeders, carousel motors, etc...  They are not coordinated motion axes but instead are totally independent of other axes.  OOB axes use the scripting jog methods for motion and they can be homed.  So one can use incremental or absolute jogging for precise positioning.  Or velocity based jogs as a percentage of max velocity or feed per minute.  No G code will ever move one of these axes in coordination with any other axis.  Meaning that no axis letter can be assigned to them.

Contrary to the feature matrix on the website, the Hobby version has all 6 OOB axes available.  It was Mach4 Lite that was limited to only one OOB axis.  Obviously, one would need a motion controller that could control at least 12 motors to take advantage of every coordinated and OOB axis.  So...  you quickly get out of hobby territory, price wise. 

Not all motion controllers support these OOB axes.  So check with the controller vendor first. 

Steve

615
Mach4 General Discussion / Re: Spindle at Speed
« on: May 09, 2018, 06:50:59 PM »
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

616
Mach4 General Discussion / Re: Spindle at Speed
« on: May 09, 2018, 02:30:12 AM »
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

617
Mach4 General Discussion / Re: Lua Stats
« on: May 03, 2018, 06:10:41 PM »
Any LUA compatible 5.2 module library can be placed in the Modules directory and used.

Steve

618
Maybe.  It depends on wxLUA.  I have to get 5.3 compiling with that first.  I want to move to wx3.2 when it comes out before I try getting 5.3 going.

Steve

619
No docs yet.  :(  And there is nothing that will list the properties of a control.  But there is a function to enumerate the controls of the screen.  But only in the very latest builds of Mach. 

For all controls that have a background image, there is a scale method property.  When a screen is built, you choose a resolution.  But the screen may not be actually run at that resolution.  Therefore, all of the controls and images are scaled accordingly.  Scaling controls is easy.  But scaling images is a bit harder.  Especially if the scaled image is BIGGER than the original image because pixels have to be added!  So that isn't a good thing at all.  The fix for that is make the image bigger (pixel wise) than it will ever be displayed scaled.  That way, the image is always scaled down.  But even scaling an image down has it's issues.  Now we are going from more pixels to less.  So there are multiple formulas (scale methods) that accomplish this in different ways.  Some images will look better when scaled with certain scale methods.  You have to choose the one that looks best for your image. 

In the hobby version, the buttons are standard Windows controls.  And they do things that I may never be able to "undo".  In the industrial versions, I wrote my own button that I have complete control over (Advnaced GUI controls).


Now, buttons with transparencies are problematic.  Because when the button is pressed, it does move up and to the left to give the effect of being pressed.  This is not an issue on an opaque image or regular button because all of the background is repainted.  But the background is transparent!  So that part of the background is NOT repainted.  It is not a bug, per say, but just how the windows operating system works.  In the hobby version, the buttons are standard Windows controls.  And they do things that I may never be able to "undo".  In the industrial versions, I wrote my own button that I have complete control over (Advnaced GUI controls).  I would need to see your screen set to determine what is going on.  If it is an actual bug or if it is the Windows stock button issue.  But I think from your description that it is the stock windows button issue.  So make a ticket with Bryanna and attach your profile package (Help -> Support -> Package Current Profile).  Tell her to send it to me. 

Steve

620
Mach4 General Discussion / Re: Debugging Lua code...
« on: March 12, 2018, 07:37:54 PM »
LOL!!!  You think?  I dunno...  It hurts my brain sometimes.  LOL

Paul Kulchenko (the author of ZeroBrane Studio) did a really nice job and he has been a pleasure to work with.  The version that comes with Mach is a special version that he did up for us since the original mcLuaEditor.exe that we did had some special things inside it.  So he duplicated all of that and made it a really nice integration.  I was at the point where I really needed to spend some time making mcLuaEditor better (add remote debugging capability, etc...) but why re-invent the wheel?  Oh, BTW, that whole ZeroBrane Studio editor is done in LUA.  That shows you the power of the wxWidgets/LUA combination.  

Steve