Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Mike VT on May 07, 2016, 12:41:15 PM
-
Background,
I basically was given a 1991 Haas VF1 about 3 yrs ago. It was a bit rough, but got it up and going. The serial comms would not work and occasionally, all programs would get wiped. This resulted in manually keying in all programs all the time. Really sucked. Decided to buy new boards to fix comm issue. About 3k. Few months later, get fatal eprom errors. 90 day warranty expired. Repeat. 6 months later, same result. The boards they have are all used and just ain't gonna do this again.
Just before getting this machine, I purchased a nice Acer knee mill that was very lightly used and had a dead cnc package. I built the panel and setup mach 3. Mill has been nearly flawless for years.
But, I love the flood coolant and tool changer on the haas. So, instead of dropping 20-30k on another used machine, I'm going to do this conversion.
The x, y, z, coolant, limits, lube, I get all that. Where I am a little fuzzy is the tool changer operation. I fully understand the process that has to happen, just not sure exactly how to implement with mach.
Good news is that I do a lot of PLC programming and actually use Modbus TCP quite often. I haven't found any real step by step on doing this but I get the impression that it will be a custom macro that will send the tool number to the PLC. PLC would do the following.
Verify spindle is stopped.
Move to carousel height
Rotate spindle at min speed and engage orientation lock pin and stop
Engage shuttle to move in, check limit
Release tool and stay released
Move spindle to carousel clearance plane
Rotate carousel to tool x
Move spindle down to carousel height
Engage tool
Retract shuttle and check limit
Return something to the marco indictating success or failure
On to my questions. Am I correct in thinking that the macro to Modbus TCP to PLC and back is the solution?
Or, can mach do this more directly. Assume you would need the dual parrallel port if mach is handling the whole thing.
I am familiar with Mach 3 on my knee mill. Is mach 4 going to be more suited to this?
Bunch more questions, but lets start here.
-
Personally I would look at one of the higher end controllers available, might actually not work out much more expensive as you will not have to convert 24v-5v and vice versa.
Also if the servo drives are good then may be worth looking at one of the analogue command capable controllers and keep the servo drives you have.
Not used TCP modbus but have used serial modbus for PLCs on machines and works well...
Hood
-
I'll echo Hood's comment about using a higher end controller that can handle 24V.
CS-Labs CS-M__/_, Dynomotion KFlop+Konnect (Konnect is a 24V IO expansion boards, if you've got analog servo drives, you'd want a Kanalog board as well), Vital DSP or HiCon, and Galil controllers can all handle 24V.
They also remove the need for parallel ports.
By the looks of it, that tool change sequence would be better handled in a single place, which would vary depending on what controller you use.
It could all be handled within Mach with enough IO. My only concern would be how quickly Mach would be able to stop the spindle on detecting the pin alignment, as Mach3 only has 10Hz update rate for Macros (Mach 4 is faster, but I've not been aware of any specific figures).
My personal preference would be a KFlop, as you can program it directly to handle whatever you want. Once it's programmed, it can control everything on the machine and respond near instantly to input changes, so things like tool changes, you just need to tell the KFlop what tool you want, and it does it and tells you once it's finished.
With something that relies on Mach Macros to tell it what to do, there is usually a delay in responding to input changes.
Regardless of controller choice, the first thing I'd suggest you do, is go through the machine, and make a list of all the Inputs and Outputs you'll need. Once you have that list, it'll give you a far better idea of what you need to get the machine working.
-
Thanks guys. Had not considered re-using drives but I have never had a problem with them so this will save a few bucks. Been reading up on the DynoMotion hardware and it seems really nice. Not thrilled about having to fumble around with C but looks like its doable.
I am gonna have to dig a little deeper on the tool changer. I believe the carousel and shuttle are just DC motors with no encoder feedback. Pretty sure they just index to limit switches and stop. I pull all this apart and take a closer look.
Thanks for giving me a little direction.
-
Not thrilled about having to fumble around with C but looks like its doable.
That was what put me off the Kflop, get by with very basic VB knowledge and have no inclination to learn any other language.
CSMIO/IP-A is what I use. probably not as versatile if wanting to do really oddball stuff but it has almost all you could want anyway.
Use it on my Chiron and it is the best controller I have had.
Vid of Chiron doing my first rigid tapping test.
https://www.youtube.com/watch?v=GNL2XdsJz2E
I used a PLC for the toolchange for 2 reasons, first was I already had it doing nothing, second I am better at ladder logic than I am at VB.
Hood
-
This sounds like good advice. The C is not desireable. I'll check it out. Thanks
-
Okay,
I have gutted the Haas. On a side note, I finally found the source of a mechanical issue I've had. Was not cutting circles well at all. Turned out to be nothing more than xy not perpendicular. Easy fix. Wish I could fire it back up and cut a circle. But, it is gutted.
So, I have three DC brushed motors and 3 haas drives that were all working fine. I attached a picture of the drives and wondering if somewhere could confirm that these are probably serial interface drives. I really don't want to use the OEM drives anyway as that is kinda the point to this whole thing. Been looking for DC servo drives wanted to see if you guys could throw out some companies to consider for 3 new drives and and keep my motors. Seems like everything is AC servo drives. Not finding a lot of options for a DC drive.
Also, not sure what the KW rating of the motors are but... the Drives have a 10amp fuse on the 160VDC supply. Also, the 160VDC wires look to be only 18ga wire. So at most, the motors are 1600 watts and more likely in the 1-1.3kw range. Thoughts on that logic?
-
Afraid I don't know anything about these drives but they must be pretty old and I would suspect that they would be +/- 10v analogue signal control.
There are a few people that do DC drives for the hobby end of the marked, probably www.cncdrive.com would be worth a look as I think they do drives that would be suitable for these voltages and currents.
For more Industrial related drives maybe http://www.a-m-c.com/products/drives.html
Personally I would have left everything intact and just wired the controller to the original wiring/drives etc but if you don't have wiring info then that may be a problem and as you have already stripped then it's not an option now :D
I think I would still use the original drives though if a manual or tech sheet could be found for them.
Hood
-
Struggling a bit with finding hardware to play with each other. I have DC brushed motors and 160vdc power supply. Had settled on the CSMIO in the step direction model. This was because I'm not having much luck finding analog drives that will handle the 160VDC and accept diffential encoder input. So I want to use the DG4S-16035 drives. Mainly because they handle my existing power supply which is a really nice rectified 3 phase setup. Also, these are the drives I used on my knee mill conversion and I have been quite happy with them. Thirdly, cost and availability can't be beat.
But, after carefully reading the CS Labs manual, I come accross the fact that their step and direction signal is differential. The drives only accept single ended. This is becoming a silly little circle. Can't really fault their choice as it is the best. BUT, Mach is based on single ended signals from parrallel port so it would have been nice to offer it both ways or atleast match the market that Mach created. Of course I could buy their AC Drive and Motor package for nearly 2K which I would almost consider except, its a reduction in wattage and I would have to deal with the mounting and shaft issues.
Hood, I saw in another post where you have used the DG4S drives with success. Did you have to deal with the Differential vs Single ended issue on the step and direction? A Single to Differential converter is easy to find and readily available. Going the other way, not so much.
-
Never mind Hood. I found that CS Labs has exactly what I need.
Finally, I think I have a combination that will work.
-
Never had those drives although a friend did.
You can easily make up your own line receiver, only thing you need is the line receiver chip and a bit of vero board and some wires, I think one I have used in the past was AM26C32-EP
Hood
-
So things are coming along. Panel is just about wired. Haven't settled on a new spindle drive yet but figure I can play with X,Y and Z before worrying about spindle and tool changer.
Now to setting up software.
Mach 3 or Mach 4?????
I'm familiar with Mach 3 so probably leaning that way. Thoughts?
-
Personally, I would always stick with familiarity ;)
-
I got the x,y,z and spindle going yesterday. I used Demo version of Mach 3 for now.
Was able to get about 500 inches/minute which is smoking fast. I turned everything back to 300 in/min just because 500 will scare the heck out of you.
Gonna get the spindle gearing setup correctly today in high gear. Then I will start working on the gear change. This is where I'm hoping you guys can help.
-
Have some issues with home and limits. Homing is perfect. But if i jog onto a limit, it is issueing an estop and disabling everything. Have to turn on emulate for that switch in order to jog off. Cslabs has a smart limits setting that seems to do nothing. I'll get it figured. Writing first script for gear change.
I have figured out how to get the requested speed and I get the idea of slowing down to change gears. Issue I have is how to catch a simple S200 entered into mdi. Thats not a M03 command that I can edit in the m3 script.
Idea would be we are running 2500 rpm on pulley one. Threshold for gear change is 900. A S500 shows up in mdi or in gcode program. How do I catch that.
-
My new panel
-
I have figured out how to get the requested speed and I get the idea of slowing down to change gears. Issue I have is how to catch a simple S200 entered into mdi. Thats not a M03 command that I can edit in the m3 script.
Idea would be we are running 2500 rpm on pulley one. Threshold for gear change is 900. A S500 shows up in mdi or in gcode program. How do I catch that.
Have a play with SpindleSpeed.m1s macro - might do it ;)
-
Got the gear change working just fine. First VB code I ever wrote. But now I have a problem that is Mach related.
If I am running or was running in low gear at 500rpm and stop the spindle with M5. My current pulley is Number 2
I now enter M3 S2500 (my threshold for gear change is 999rpm.
Mach looks at my pulley 2 max rpm and figures out it is too high. It throws a warning and reset my speed command to the max in the pulley setting. Then it calls M3 macro.
So the problem is, I have the code in the M3 macro to look at requested speed (Mach just changed it) and decide if gear change is needed. Also, as part of that macro, we set the new pulley to number 1.
I can't just change the pulley max rpm as that is directly tied to the analog out that runs the drive. Right now, at all speeds in any gear, I'm within .5%.
Is there a way to tell Mach to ignore max speed? Or is there a place it puts the original request that I could go get?
The issue is that when it finally shifts gears, runs the spindle up- I'm stuck at the low gear maximum. That ain't cool at all. Easy way to break a tool when I requested 4000rpm and in runs into the material at 1300rpm with only a note at the bottom of the screen. Hoping there is something in there to fix this.
-
I think the number one question is
Did they throw the data away (the original speed request) or can it be plucked from somewhere?
-
As Dave has mentioned, the spindlespeed.m1s macro is where you want to be looking at the selected rpm and deciding on the gear.
Hood
-
Okay, Don't know why I didn't figure it out yesterday while on the machine. Playing around today, It looks like I have to Catch the speed request inside of SpindleSpeed.m1s.
Just as Dave pointed out. I think I tried to be smart and failed. Figured I didn't need to go into SpindleSpeed if I was doing an M3. Clearly an M3 (which has a S???) goes through the SpindleSpeed call first and then runs the M3 call. If the returned value from SpindleSpeed exceeds the current Pulley max, Mach changes it to Max and then runs M3. I get it. I knew there was no way that I write my first script and run into some fundamental bug. I will try to dumb myself down moving forward.
Thanks Guys.
Feeling like the tool change is going to be very manageable. Been a little nervous throughout the re-wire that I wouldn't be able to complete the changer and would end up with a basic knee mill. This stuff ain't bad at all once you dig in a bit.
-
I wish I was at your stage, but still wrestling with the mechanicals, I love the wiring and debugging part :)
-
Just an update. I have the gear change working well. Its funny, I figured I would start learning the scripts with Gear change thinking it would be much easier than the tool changer. It actually is more difficult because of the way SpinSpeed and M3/M4 are tied together is not so obvious way. But it ended up being a great learning experience.
I ran into a problem where anytime I used an "IF NOT GetInBit(?) THEN" statement, it always returned true irregardless of the input state. Had no clue what was making my programs do silly stuff. Finally narrowed it down to a plug-in issue I'm pretty sure. If I use the "IF NOT GetOEMLed(?) THEN", this works as expected so it's not likely a mach issue. But if I call on CSLABS hardware, it never worked. A regular "IF GetInBit(?) THEN" statement does work correctly. I emailed CSLABS support and waiting on reply. As a workaround, I can do this.
"IF GeTInBit(?)=0 THEN" and this works inplace of using the IF NOT.
So I moved on to the tool changer and found it to be rather straight forward so far. I am able to orient the spindle with no speed or timing issues straight from the CSLABS I/O. Tool carosel seems to have no issue landing on the correct tool with the geneva cam setup. Never really paid attention to how they work and now I get it. Awesome design. Instead of trying to land within 1 degree or less, you now get to just land within 180 degrees and you are good. Clever solution.
So I have it where the Z, Carosel in/out, and Carosel tool select all work in harmony. I want it to work as close to the original machine as I can. On power up and Homing, the Haas always homed the z, then x and y and then it would go put the existing tool in the current pocket. Raise Z to safe and run carosel to tool 1 and load that tool.
I like this and it makes perfect sense to me. It seems Mach likes to just load up with tool 0 and its up to the operator to not forget to fix this.
So couple of questions:
What would be the best way to add carosel and tool 1 selection when homing all?
Can I eliminate mach displaying a tool zero. Instead, all tools are 1 through 16.
Thanks,
Mike
-
Ran into the same thing with the Not GetInBit() just a few days ago whilst trying to write a macro for a friends lathe turret. It has been kind of awkward as I am emailing files and trying to get things working without actually being able to see what is happening. Hopefully I have it now, ended up using a Do Loop rather than a While No GetInBit.
It brought something to mind however, I seem to recall that If Not GetInput() wouldn't work, that is the call for Modbus input and the CSMIO's use their own internal Modbus so it may actually be Mach that is the problem with the Not
Does the Persistent Tool Selection option on General Config not work to keep the tool number correct. If I recall it works fine on Mill and half OK on Lathe as it will dump the lathe offset but keep the tool number, but as said Mill should be fine as you call the offsets separately in Mill.
Hood
-
Thanks Hood. The persistent tool seems do what I need.
CSLabs got back and is pretty sure it is a Mach issue. They were able to dupilcate the issue using GetUserLed so it's not just when their hardware is called. Using the If ....=0 seems to take the place of IF NOT just fine so I'm good. Wonder if Mach 4 has similar issue?
-
There is no "if not" bug.
getInBit() and getUserLED() are INTEGER functions which return 0 or 1.
Contrary to (seemingly popular) belief, the integer values 0 and 1 are not 100% equivalent to false and true. (at least not in BASIC).
To use integer expressions correctly in logical contexts they should either be explicitly cast to booleans or perhaps more normally, explicitly compared to the required values. In the second case of course, the comparison itself yields a boolean result, hence no need for casting.
So why (I hear you ask) does getOEMLED() work just fine with "if not"?
Simply because it is not an integer function, it actually IS a boolean function.
The moral of the story? - don't indulge in type abuse - it'll bite you sooner or later.
-
This makes perfect sense. I probably made stupid assumption thinking about modbus with coils and registers and then seeing the "bit" in GetInBit.
So I think you are saying that I should never have this:
If GetInBit() Then...
But instead, it should be
If GetInBit()=1 Then...
Thanks, I think this helps alot. Don't think I ever looked at what Type anything was. Thats not cool at all.
-
This makes perfect sense. I probably made stupid assumption thinking about modbus with coils and registers and then seeing the "bit" in GetInBit.
TBH there's no particular reason that immediately comes to mind why it SHOULDN'T have been written as a boolean function. But tis what tis.
So I think you are saying that I should never have this:
If GetInBit() Then...
But instead, it should be
If GetInBit()=1 Then...
You got it.
But please remember, this is for NON boolean types. If the type IS boolean - please don't write this sort of nonsense:
if someBooleanExpression = false then...
-
I get it. Respect your Type.
Thanks
-
Got a bunch of issues with FEEDHOLD.
So I added a Stop, Cycle/Start and FeedHold switch to my panel. Started playing around with these to insure they work.
First, issue- Feed Hold is ineffective at quickly stopping the feed. Read up on the forum and sure enough, it's gonna keep right on rolling until the buffer on CSLabs is finished. Actually, it seems more like its going to just coast to a stop some time in the future. But let me finish.
I started to mess around with 3 different Mach 3 Installations.
Mach 3 On Desktop that nothing has been really confirgured at all. Not on any machine.
If you run a program, hit FeedHold, it shows a delay and pretends to stop at the point that it coast to a stop. Press start, it pretends to continue on from that point.
Mach 3 on an actual Knee Mill using an actual parrallel port.
If you run a program, hit FeedHold, it has a significant delay before coming to a stop. Press Start and it backs up to the last known point which is the last line in the G-Code program. Works Okay as long as an arc wasn't being executed when you hit the feedhold.
Mach 3 on the Haas using an external motion controller (cslabs)
If you run a program, hit feedhold, it has a "very" significant delay before coming to a stop. Press Start and it goes to the next point in the G-Code file. Thats a straight line tool path right across the part.
I get a feeling I already know the answers to my questions but would like to hear it. My guess, in desktop mode, works like a champ. On actual machine with parallel port, a semi fix was added to back up and hope for best. On an external controller, all is lost because there is no "packet control" on what was sent, received and whats remaining.
I have been searching this topic and am quite surprised it has not been more vocal. The cycle/Start and Feed/Hold are the most used hard switches on a VMC. Admitteldy, I have had Mach 3 on my knee mill for 3+ years and never really paid attention to this. On the VMC, its different because I have a Z that is very fast and I have a bunch of different tools with different tool lengths. Number one thing I use the Feed/Hold for is Z moves on the first run. I like to hit it just short of contact and do a quick check on the distance to go. Saves a lot of unexpected (operator/programmer error) crashes and lets you do the first run with moderately fast moves. Thats not going to happen on the way it works now. Actually, the way it works now seems to completely make the Feed/Hold about as dangerous as it gets. Unresponsive and unpredictable.
Really hoping someone has insight. Have seen suggestions to use older version of Mach. I'm open to that but would also like to have a clue of what issues I will be facing right out the gate.
-
Or, I'm open to Mach 4. Lot of time in this and right at the end. Putting all guards back on tomorrow and in theory start running a bunch of parts next week.
Little nervous that I make a stupid mistake when choosing how to control this VMC based on my experience with a simple 2 axis knee mill.
I get that I may have to operate the machine differently than I'm used to. But what I'm seeing here is that if I need to "Pause" the gcode program, I have no choice but to start the program from the beginning or Stop It and do Run From Here (always confusing). Thats a hard pill to swallow on very large programs and if true will leave machining marks in the part making them un-acceptable for delivery to customer.
-
Don't often use feedhold on my machines as I have an external pot for feed override and use that all the time, especially on first runs, it too is delayed a bit but a log pot helps greatly.
Regarding the IP-A not coming out of a feedhold correctly then I have never seen that, on the odd occasion I do use it it has worked fine.
I presume you are not pressing Stop after the motion has stopped? If you are then that is your problem as it clears the buffer and it will just start from the next line.
Ver 066 is screwed up, use it at your own risk is all I will say.
Hood
-
Thats atleast a start. Pressing a Stop at anytime just kills everything and sets the gcode program to first line. So, in my example, I am not pressing Stop after a Feed/hold. If I do, it just resets the entire program.
So, I guess I should revert to an ealier version and find out whats wrong over there....
I get it. So goes the worm. As you eat, you dig deeper. (I just made that up, its pretty good I think)
-
Its probably some 8th century poet wrote that and I am just showing my stupidty in thinking I'm clever.
-
Not sure if my code reverts to the beginning or not after pressing Stop, don't recall it doing so but possibly, will have to check tomorrow.
One thing, pressing Feedhold in and MDI move can not recover. You have to press Stop or maybe even Reset, can't quite remember, but after you do that you can then command another MDI if required.
Been looking again at Mach4, just messing around with it in Simulation but it is instant on feedhold and it is that way with external controllers as well, or so they say. Not sure how far on the CSMIO plugin is as I gave up a good while back as Mach4 kept changing and I think plugins were needing ground up rewrites. Think Mach4 has been stable since those days, as far as major updates are concerned, so maybe I will try it out on the Chiron at some point in time.
As said at the moment I am just messing about with it on the desktop, modifying the lathe screen, adding custom buttons, DROs etc and trying to get to grips with Lua :D But is very powerful and makes doing custom things very possible.
Hood
-
Hood,
So what would be the proper procedure to install a previous version. Don't want to loose all the settings and macros.
Also, can you give me link to older versions. NewFangled site only seems to have 66 linked?
-
Always best to have a backup of stuff you do not want to lose,so easiest way is copy the whole Mach3 folder to another location.
Ok as for installing a different version, if you have a custom profile then it should not be a problem, all you do is run the exe from the version you want and it will do its thing and all your custom stuff will be intact. But even if something very weird did happen you would have your custom stuff backed up ready to replace.
If however you are using a default profile then you will need to replace your macros etc after the install, again just a matter of copying the macros etc back after the install.
Older versions of Mach can be found on the ftp site, 062 is what most use.
ftp://machsupport.com/Mach3/ (ftp://machsupport.com/Mach3/)
Hood
-
Wow. They sure buried that link. Finally found out how to find it.
http://www.machsupport.com/ Must Highlite "Software And Downloads" Then choose MACH3
On Left, choose "Downloads and Updates" http://www.machsupport.com/software/downloads-updates/
Now choose "FTP DOWNLOADS"
Then choose "FTP SERVER-MAIN MENU"
Then Choose MACH3
Then PICK YOUR POISON
Can't believe I had to post to find out how to link to an older version. I get a feeling I'm about to be banned from this site. With a valid reason for once. Come on guys.
-
LOL yes it has always been a bit hidden for some reason, don't think it is deliberate as such, just programmers are weirdos ;D
Ok ran some tests, feedhold takes about 1 second for me but I ran some code and during the code I pressed Hold then Start at least 20 times and it worked no problem each time.
If I pressed Stop after a feedhold then the code stayed where it was, it did not rewind. Might be a setting in the plugin you have different, not sure.
Hood
-
Hood,
I have test driven version 62 and mach4 with mixed results. Can't completely say what is happening in each one yet but issue seems consistant across the board. Their seems to be a major delay in stopping when using feed/hold.
I am attaching a gcode file. Its in inches. This part is nothing but radiuses. Hoping you would be kind enough to play with it. What I have noticed is that if you play with this file and hit feed/hold and start, you will see the issue. It seems to just depend on when you press the Hold. Eventlually, you will see your tool path cut across the part to the next known gcode coordinate. This is true on a desktop setup with/with parallel port configured and its definately true on the actual machine with cslabs.
Even 1 second is insane. At 300 inches per minute, that's 5 inches per second of travel. On a commercial machine, hitting Feed/Hold stop the axis about as fast as the decel time would allow. A few milliseconds. And of course it would know where it is at when all was said and done.
I think if you have a bunch of linear moves, the problem is completely hidden unless you happen to get it hung up on a corner. My guess is that even though it appears to be right, I bet a bunch of steps are lost. Could only know for sure by running an actual part and doing the Start-Pause-Start...... over and over and then check the part. I bet its crap.
-
Oh, be sure to crank up the speed. File is running at 10 inches per minute. Try it at much higher speeds to see the issue, although, I have seen it at even this low speed.
-
Ah I think the issue in the Arcs may be a Mach problem.
Yes I know 1 sec is slow but it is what it is with Mach I am afraid hence why I use a pot and even that is delayed but you get used to it.
Hopefully Mach4 will prove good enough to start using shortly, it will depend on the progress they make with the plugin of course.
Hood