Messages

1

Works in progress / 1024_RPM.set With Amps and Freq display for HungYang VFD

« on: July 01, 2019, 09:46:04 PM »

This is "a down and dirty" edited version of the 1024_RPM.set from this post: https://www.machsupport.com/forum/index.php?topic=21899.0 which is an update of 1024.set included with Mach3. I've added two additional user DROs to display VFD frequency and VFD amperage from the http://royaumedeole.fr/informatique/plugin-mach3-pour-vfdhuanyang/mach3-plugin-for-huanyang-vfd/ (Le royaume d'éole)

Configure the RPM display by selecting the dropdown for RPM then enable the user DRO by setting it to 2222
Configure the frequency display by selecting the dropdown for frequency then enable the user DRO by setting it to 2223
Configure the amperage display by selecting the dropdown for amps then enable the user DRO display by setting it to 2224

2

General Mach Discussion / Re: Closed loop control using encoders?

« on: December 04, 2013, 11:23:53 AM »

Tom,

Why not take a moment and run some tests on scrap stock to see what your machine can do with different tools and see what
feedrates you can use.

I've done that and I have a general idea how hard I can run against various materials but just when I think I have it figured out a part comes up short. This machine has so little overhead it makes sense to me to use whatever tools I can to help me run it at it's best, especially when it can make the difference between a 4 hour run at plodding speeds with burning hot bits and a 1 hour run with reasonable chip loads.

In general you should have the velocity and accel values set that you have headroom which would allow for
things like a knot in the wood or whatever. You have what you have and running anything to it's limits without proper consideration
in the program to address the task at hand just shows lack of experience.

I echo what Ray replied if your machine dosen't satisfy your requirements.

RICH

Why are you and others so against encoders? It's not the tool that makes or breaks a well run machine, it's how the tool it used. Encoders are just another part of the tool. And, I still agree that machine tuning is the key. I'm not after a closed loop system, I'm just looking for a faster, more accurate way to learn what I can and cannot do with what I have. It's better to measure it directly than test and guess. It could take days and days of testing to make a chart of feed rates that may or may not be transferable from one material to another and testing does nothing to address bit wear or sharpness. Obviously I have a lack of experience or I wouldn't be having issues. But experience alone won't help me run this small hobby machine at its limits. I suspect you're using a much more capable machine than I am so it's easy to say "just tune it and forget encoders". If you have a NEMA 34 or larger motor you have literally 5 times the torque I do. 380 oz-in motors don't have much overhead when driving against a 1/2" bit mounted in a router plowing through hardwood plywood. Feed rate changes as little as a few IPS under those conditions make the difference between a toasted bit and a successfully cut part. A pinion gear encoder setup may make the difference between a part that's only a few thousandths out of spec and completely ruined work. The bottom line is that for the miniscule cost of a few encoders, two hours of time and a breakout board I can find out for sure exactly what moves are causing positional loss. Since I have R&P drives I've decided to install a pair of shaft encoders mounted on the X and Y axes driven directly by a secondary pinion gear. The setup will allow me to detect and address backlash as well as help prevent ruined work. It will alert me that I need to home the machine as part of a bit change if it's begun to creep. It will provide me with very useful information that I didn't have before, information that cannot be easily measured any other way.

Lastly, the original question was, does Mach have a facility to alter or augment it's overall program execution? The answer is "yes", it's called "Brains". That's all I really wanted to know but it doesn't hurt to share opinions.

Tom

3

General Mach Discussion / Re: Closed loop control using encoders?

« on: December 03, 2013, 11:52:45 AM »

Why not simply FIX your machine?  A properly designed, properly operated stepper system will NOT lose steps.  Encoders are totally unnecessary, and are nothing more than a band-aid to hide the real problem.  Lost steps are ALWAYS a direct result of attempting to operate the motors beyond their capability.  Either slow down to stay within the machines capability, or improve your stepper system (bigger motors and/or better drives and/or higher voltage) to make it perform the way you want.

Regards,
Ray L.

Thanks for the feedback. I agree that fixing the machine is the best option but ignoring a tool that I could use to help learn more about machine limits is just as stupid as adding a bigger spindle to a cheezy eBay machine in hopes it will cut faster. I have been continually tuning things as I go, learning what this machine can and cannot do but I have no clear way to determine what effect the changes produce without ruining work, which I can't really afford any more. I have a cncrouterparts 24x48 kit machine with R&P drives on X and Y and lead screw on Z. I've checked and re-checked rail bearings to make sure they are zero play but aren't binding, varied acceleration and max IPS values in motor tuning, changed pulse widths and even experimented with Sherline mode. What I've determined is that even with fairly high accel and max IPS values I don't loose position just jogging around or under light load, even when rastering, so it has to be router kickback and/or too high a feedrate for bit/material combination that is overloading the drive motors. I started my tuning by following chip load charts and quickly discovered that with larger bits (3/8">) I cannot even begin to approach the feed rates necessary to stay within recommended chip loads for larger bits so my concern now is to find a feed rate that cuts without bit burning. Especially on hard to cut materials like plywood. I toasted a brand-new router motor and a good 3/8" compression bit, and even got a small fire going while learning about heat build up. But, to do that I need a way to accurately determine exactly which moves are causing lost steps and I need to determine that limit before the work is ruined. Is accel set too fast, pulse width wrong for my controller, router RPM too low feed rate too high? Would an air blast to clean out deep cuts be helpful? All questions that the information an encoder can provide will help answer. If I do upgrade motors I'll probably get away from Mach3/Windows altogether and go to a Linux solution so I can install and use feedback steppers. But I don't really see that happening.

Finally, I agree that closed loop is not a way to overcome poor machine setup and/or tuning. But encoders can also be a very a useful tool to help one learn and explore machine limits without destroying work in the process. And that is what I'm after. The pseudo offset-update-regen process I noted would only work if there were only very occasional positional losses, if the machine were already tuned and running at its limits. For one thing the machine would continue to run till the buffer were empty so any correction would come as much as 8 seconds after the error was detected. If the machine jammed that process could actually cause machine damage, especially if it continually updated the offset and kept retrying to move. And, the first move after a regen would need to be only a very few steps to be useful, otherwise it would destroy the very work I'm trying to save. It could prevent continual positional drift in a long run though. But it definitely won't make the machine cut any faster.

I guess what I was asking is if there is a way to get inside the Mach process and set breakpoints or triggers on events etc. Most software like this has some kind of built-in API hooks so one can add subroutines to the main processing loop and trap different conditions or insert loops at various logical break points. Mach must have some kind of facility like that.

Tom

4

General Mach Discussion / Re: Closed loop control using encoders?

« on: December 02, 2013, 11:17:49 PM »

I know this is an old thread, if I get no response I'll start a new one.

I too have an issue with occasionally loosing steps. I'm thinking of adding encoders to my NEMA 23 motors but then comes the issue is what to do with the additional information. Because of the way Mach renders the Gcode to machine moves, closed loop operation is out of the question without an external device to manage the error. But, my preliminary testing indicates that Mach3, being a buffered system, probably pre-compiles the input gcode file producing a second file of actual machine moves that are then used to drive the motors. This second copy includes the effect of tool offsets, work offsets, rotations, scaling etc, and is generated whenever you load a Gcode file or press the "Regen Toolpath" button. Since I use Mach as a 3 axis router a small amount of error while cutting is acceptable. My X and Y axes have about 0.002" resolution which will make little difference cutting most of the things I cut. My idea is to alter the current work offsets by the error amount then "regen toolpath" to update the DRO and continue. I've discovered that its possible to successfully regenerate the toolpath during a feed hold. Once you cycle start again the DRO position makes an apparently G1 type move to the next position and begins running again. If the error is small, say less than 5 actual steps in X or Y or even as many as 20 in the Z, the effect will be almost unnoticeable.

Does anybody have any idea where I might find more information about writing code to accomplish such a task?
VbScript? Plugin?

5

General Mach Discussion / Re: DoButton vs DoOEMButton

« on: June 02, 2013, 01:00:03 PM »

I don't know why the ESS plugin does not support RefCombination yet. Greg at Warp9 says not to use it until he publishes his next plugin. I don't know if that means the just released version (v10h2d1a) or the to-be-released version. I asked over there and will hopefully get an answer soon.

Greg at Warp9 says it will be the next plugin, not the recently released  (v10h2d1a) version.

6

General Mach Discussion / Re: DoButton vs DoOEMButton

« on: June 02, 2013, 12:58:22 PM »

Is it homing the slaved axis first because it sees the slaved axis home switch first? 

It does not seem to make a difference which switch it hits first, It seems to be looking only for the slave switch on the initial move. I don't think it's looking for both but I could try pushing the master switch forward and see what it does. As near as I can tell, during homing it moves the combined master/slave axis towards the switches then stops when it apparently hits the slave switch. It then backs off both axes together until the slave sensor opens. It then uncouples the axes/disables slaving, homes the slave side again only this time it moves ALONE and SEPARATELY, backs off the slave side till the switch opens, homes the master axis separately until it hits the master switch then backs off and stops. It definitely does a more complex move than if I home it to Y alone and it definitely homes the axes three times. I can hear it move the motors. Once with both motors then each motor separately. I'll see if I can get a video of it in action so I can see exactly what its doing.

The problem I'm having is that when it homes the slave side first it's twisting the gantry slightly in the process. Then it homes the master side releasing the twist in the gantry when it pulls the master side back to square but when it does so it moves the gantry towards the switches enough to trip the prime sensor again. Initially I just disabled the prime sensor as a limit switch and it works fine as long as you don't try to home twice in a row. But if you hit Ref All Home or try to home the Y twice it doesn't detect the prime switch being tripped and tries to home past it, even though it's tripped. Definitely something it should not do and what I consider a bug. I might be able to prevent this from happening by moving the switches to the far outside of the gantry so the twist has less effect. I'll go fiddle with it some more and see if I can get video to post. I may need to report this as a bug.

I wonder how it would work if it sees the other axis home switch first?  Could you try that before squaring your gantry?  Squaring the gantry mechanically is a must IMO but I would be interested in the results if you do test. 

I have tested auto squaring with the gantry out of square before the homing. The machine works fine except if you hit eStop or lock the operator and release holding torque on the motors which, of course, causes lost or gained steps. With the gantry square to begin with there isn't enough gantry twist to move the motors if you hit eStop. I discovered the issue when I was cutting a 3D shape. I hit eStop for some reason and didn't resquare the gantry and it changed the X axis path across the piece. Not enough to ruin it but I could clearly see the horizontal line where it lost or gained a step. What I need are encoders for the stepper motors but I don't think Mach will make use of them even if I install them. I'd only be able to use them to detect missed steps with an external comparator. It would be easy to set up a circuit that counts and compares pulses from the motor and the encoder, setting an error condition if the count is out of sync which I could trap using an input. I think there is just such a board somewhere. Unfortunately Mach does not support feedback steppers, only servos.

Tom

I'm just wondering what the sequence should be and if it will make a difference.

I can push the master switch forward while its squaring and see if it makes a difference.

  I think it may well do it and if so, you will want to know before you square the gantry and set your limits.

Brett   
[/quote]

7

General Mach Discussion / Re: DoButton vs DoOEMButton

« on: June 01, 2013, 10:13:37 PM »

DoButton was replaced by DoOEMButton at some point, but DoButton still works. Don't count on ever seeing mature reference docs.

Yea, I found the reference and both DoButton and DoOEMButton work, but, having Y slaved with A I assumed they would home separately as-in "DoOEMButton(1023) and a separate DoOEMButton(1025)  but they don't. When I home Y with DoOEMButton(23) it homes the A slave axis first, then the master Y and DoOEMButton(1025) does nothing. Before you ask, no I do not have "slave with master axis" checked in general config. I'm having an issue with the gantry being slightly out of square before homing so after A homes to its sensor the gantry twists a tiny bit turning the slave (M4Home) home switch back on again. I can disable it as a limit switch but I'd rather solve the issue. I'd like to be able to set up an auto start script that homes all axes and either a fixture or user button to move to a "stop" position so its close to the sensors when I turn it back on.

My first order tomorrow is to loosen the gantry mounting bolts and twist it manually until it sits perfectly square before homing then hope it won't twist enough to reset the "prime" home/limit switch when the other side homes. I have fixtures that depend on the gantry being an exact distance from the metal stop on the end of the gantry travel and the way it is I can't depend on it homing correctly. I also would like to

Is there a way to home the axes separately?

8

General Mach Discussion / Re: DoButton vs DoOEMButton

« on: June 01, 2013, 11:05:38 AM »

OEM Button codes are here:
http://www.machsupport.com/MachCustomizeWiki/index.php?title=OEM_Buttons
Home X would be DoOEMButton (1022)

But it's no different than DoButton(22) (which has always been used in the default Homing scripts.

I can't believe that the Smoothstepper continues to have homing issues that have been around since the initial release.

Why does the reference say to use DoOEMButton and not use DoButton? Confusing...
So DoOEMButtion is DoButton plus 1000. But the original 22, 23, 24, 25 axis references are not in the reference list. Again, confusing. But I also understand how much work goes into writing these references and how long it can take to produce a mature reference document so thank you for helping.

I don't know why the ESS plugin does not support RefCombination yet. Greg at Warp9 says not to use it until he publishes his next plugin. I don't know if that means the just released version (v10h2d1a) or the to-be-released version. I asked over there and will hopefully get an answer soon.

9

General Mach Discussion / DoButton vs DoOEMButton

« on: June 01, 2013, 10:47:04 AM »

I've been having difficulty auto squaring my slaved axis. The script that comes with Mach3 uses "DoButton(x)" but all the reference material I've seen says this is deprecated and should not be used. The references (2010 version) say DoOEMButton(x) is preferred. I'm also using a smoothstepper and apparently cannot use RefCombination() yet due to an issue with the plugin. The programmers reference says to look for "CB Constants" as a reference to the axis numbers to use with the DoOEMButton() call but I cannot find any such section in any of the programmers reference or other documentation. What gives?

Does someone have a listing of OEM button numbers that includes the axes and maybe an example using DoOEMButton to zero an axis? I want to be able to square the master and slaved axes separate. If I don't I end up with the slaved switch tripping after the master axis homes.

10

General Mach Discussion / Re: Homing slave axis revisited

« on: May 15, 2013, 11:03:06 AM »

I think I may have figured it out. Time will tell.

I was really tired yesterday after loosing several hours of work to a smoothstepper screwup that turned into a huge gouge in my semi-finshed sample sheet for a local cabinet shop. Since the A (slave) motor has no actual limit switch it seems normal that tripping the home switch defined for A would not generate an eStop. That's why the A "prime" sensor remains lit without an eStop. The problem seems to be that I got lost in all the settings and tried so many different combinations of code I failed to notice that when the refcombination(10) executes it does indeed back off the A side prime sensor. But when the Y squares later it pulls the gantry sideways and re-trips the A prime sensor because the switches are adjusted incorrectly. If I defined the prime sensor as a limit switch for A it would probably generate an eStop if the M4 prime sensor were tripped, which is probably what I want. I'll try it when I get a chance.

I went down there this morning with fresh eyes and carefully watched it and went thought my configuration again and discovered I had the Homing/Limit setting for the A axis set to reverse the DRO which, of course reverses the homing direction as well. My motors are defined different than the stock 22 tooth XML from cncrouterparts. I swapped X and Y and had to fiddle with A motor directions to get it working correctly. The A motor has to be reversed in relation to the Y motor since it's on the other side of the machine. That got me thinking I had to reverse the DRO in Homing/Limits which homes away from the switch rather than towards it. That's why I got upset and just enabled "Home Slave with Master Axis" and just used the Y sensor. The issue is also that its difficult to square the gantry without moving the tool around and measuring it. I finally measured tool to frame distance across the X axis and found that the sensors were indeed setting Y axis square with the X. So, I think it's OK. I'm re-running the same job this morning and so far, other than the smoothstepper giving me an error every once in a while, its working OK.

Thanks for the replies.