Machsupport Forum
Third party software and hardware support forums. => SmoothStepper USB => Topic started by: Cruiser on May 29, 2009, 12:18:16 AM
-
Every since I started using the SS I have had issues with the machine homing. The Z and the Y home properly but the X although it zero's and makes an attempt to back out like it should will stay in the limit trip zone by up to .0071" ! The best I could get from it is with the system set at 4khz it will clear most of the time, but at 2khz and under it will not and limit is trip faulted by varying amounts. The fact that it is of varying amounts then it tells me it isn't going to be repeatable till I get it to work as it should. I have tried and reviewed everything that I can think of to no avail. I don't know whatelse it could be or how to solve it. This was never an issue with PP and Yes I am using the up to date releases for mach 3.042.020. If I were to make a guess I'd have to say that the process is being interupted before it is done. I am leary of leaving it at 4khz and I need to know that the homing is repeating as it should. Any help would be greatly appreciated. I will attach the smoothstepper xml as it is today and from the mach root directory.
Thanks
Don
-
Don
Have you tried entering a value for noise filtering of the home input on the SS config page?
Try a value of about 200 and see if that fixes it.
If it does then try decreasing that value to the lowest value that leaves it reliable.
Greg
-
I had a low setting in the noise filtering, I tried a high setting of 200 this morning and it seemed to make no difference at all in correcting the problem. So far the best I could get this morning is .001" at 4khz and .017" at 2 khz and always the X axis which of course is the last to home in the sequence. Somehow, I think this has something to do with it, just don't have a clue as to why. Yesterday I did a touch of retuning of the gecko's with no change as well.
What else is there to check or change ? The system has absolutely NO noise symptoms whatsoever and everything else appears to be working in a pristine manner.
-
Have a look in the SS monitor page and see if there is anything flagged there which may hold a clue. Try your frequency at 1KHz or even lower to see if you can get it working. Also try referencing the X on its own and see if that throws an error.
Hood
-
I tried watching the monitor page while homing and could see the flags registering up to the point of the limit fault. I tried 1 khz slower and faster and so far the best was at 4khz but ! I tried also to reference x alone a while back but I'll try it some more after it cools off in the shop, right now I'm sitting in front of the A/C
-
I tried everything that I could think of last evening to see if anything would change, although I took notes, some of it wasn't noted properly but I'll express what I have found as best I can. I tried from 250 khz to 4k again and = 250k =-.03" / 500k = -.015 / 1000k = -.013" / 2000k = -.002"
Then I tried some differant debounce settings. Mach had been at 300 & 300 and I thought this was low enough to be insignificant but, I lowered it to 120 and thought that I'd seen an improvement, but it may have been coincidental jump in error reduction. In SS the setting was tried at differant settings and best seemed to be when kept low such as 4.29 on limit and 2.86 on home, those are multiples of the 1.43 basic setting. and a debounce of 1.2 or 3, 40 ms. The biggest changes of all were with slowing the % of feed in the homing / limits settings page down to 6% but error is still present but it got it down to from .001 to .003 inch. My thought at present is to open the optical limit housing and try cleaning the emitter and receptor with a Q tip and alcohol ? or Windex ? to see if contamination is a possible in this equation. If cleaning does no good then I'm at a total loss of what else to check change or adjust. As you can see above, some changes make a difference but nothing will eliminate an error potential. I tried numerous homes of the X axis alone and it would still fault out, but my present settings seem to be best with some errors and some clean home cycles. I'm really hoping that it is as simple as some smudge on the optics that are diffracting the light to make it have a ghosting false trip or something in that line. It seems strange tho that the Z and Y are rock solid. Maybe I need to think INSIDE the Box with the lights off to figure this one out !
-
Have you tried replacing the limit switch?? Mechanical switches are very noisey and inaccurate devices, some some dirt and wear they get worse.
-
Thanks Birt for the try ! Its optical, clean, sealed, and the problem doesn't appear to be from the switch. Yesterday I went through it and checked it out to be sure.
-
Optical huh? Have you taken a look at its output with a scope? Does the output stay on when triggered or is it only a pulse?
-
Pulse ? I think not !
-
If you can measure the output signal with a scope I would do that. You need to know what the SS is seeing. Have you tried swapping two of your sensors to see if the problem moves with them?
-
Swapping is out of the question, too destructive ! I have a vellman scope, never used it much, will see what I can get it to tell me today.
-
Did you solve this, Don? If so, or not, I'd be interested in hearing!
-
I achieved slight change by tweaking the settings, consistantly at .002" now. I'll have to live with it for the time being !
-
What actually happens on your setup?
On mine, I have an issue on "Z", but I've attributed it to the heavy knee even though it's balanced with gas springs. It homes at the bottom fine, but then sometimes the switch trips into estop again. With Z homing first, of course, if it does it I have to stop, reset and jog off, then manually home X and Y. I have optical limits and they only back off .001 or less to get off the switch and I'm thinking sometimes it settles. I have tried different shaped vanes to trip, thicker, thinner, etc. I've milled the edges so they're sharp and square. It seems it's so close, ON the switch, OFF the switch, that once in a while the Z settles .0002 and trips the switch in and out. It's actually seen flickering on the diagnostics screen!
When I saw this thread I thought, hmmmm? I've tried all the things you've tried except changing to 4khz or anything. I'm at 1khz and have never changed it. Our issues are probably different, however.
-
thosj
It certainly sounds like it could be the axis settleing back in your case, you could if you wished have it move off the Z limit by a small amount right after it homes and hopefully that would prevent it happening.
Try this in your Ref All button if you like, usual warning applies with my VB, have your hand near the E-Stop the first time you try ;)
DoButton( 24 )
While IsMoving()
Sleep 10
Wend
Code("G53G0Z-1")
While IsMoving()
Sleep 10
Wend
DoButton( 23 )
DoButton( 22 )
Oh also you may need to change the Z-1 to Z1, depending on the way your knee is set up, I would think however Z-1 would be correct.
Hood
-
Oh, hey, that sounds cool. I asked somewhere the other day if there was a way to do just that, got no reply, but someone probably thought I meant a normal Mach setting.
I'm a new Mach user, just building my machine. Can you give me a brief description of how to "Try this in your Ref All button". I have no clue, but like all the rest of this, I will know once I try it!! Do I have to use some screen editor or something? Looking forward to this!!
Could I also change the order the axes ref by doing like DoButton (23) above the DoButton (24) or something? I need to look into all this VB stuff after I get over being overwhelmed with the build. Almost done.
Thanks.
-
Some of the buttons on the Mach screen are VB buttons, ie they contain code, you can make your own VB buttons in Screen4 and put your own custom code in them to do specific tasks.
The RefAll button is a VB button and to edit it you go to the Operator menu then down to Edit VB Buttons, you will then see all the VB buttons flashing, click on the Ref All button and it will open the editor and you just alter the code in there then save.
Yes you can alter the order of homing just like you were thinking by altering which DoButton is first, second, third etc. Usually though you want the Z to home first as it moves the tool out of the way so the next axes can home safely.
Hood
-
This sounds like info I have been looking for. I've slowed down the movements to a point which allows me to watch the DRO change. With the Z and Y axis I can see where it trips, zero's, then changes to approx .008" and then backs out to zero. On the X axis however it changes to a smaller number about .006" then backs out to zero which is .002" inside limit trip zone. I'll have to re read what you suggest above and have a look see as I have believed all along that it is doing what it is told to do ! I suspect that I may have picked up something from one of the new not ready versions of Mach I tried.
-
OK, I got lost in a real big hurry ! I did as you mentioned above and opened the ref all button and then the ref x button. They are very similar and only refer to other buttons and that is where I get lost. So, that means without more learning and specific info I had better leave that well enough unchanged ! from what I've seen tho it sounds like the prg'd command is not telling the routine to back out enough or to back out till it sees the switch open for the X axis. As it is I can't prove anything either way !
-
Not really sure what you are meaning, the VB in the RefAll button is just calliing the referencing for each axis in turn, the Ref X button is not , as far as I know, a VB button so you cant open it.
Hood
-
Well, I've had an interesting experience with all this. I have a SmoothStepper. I started experimenting with Noise numbers in SS setup. If I got the Home number over about 350, the Z homing routine would go right past the switch, headed for THE END if not for eStop hit!! At about 250 is seems OK. Much lower and the switch jitters after in comes off home and trips an estop, stopping the homing routine.
So.....I edited the Ref All button per Hood's VB. Worked great. Got cocky, added moves to X and Y, too. That worked fine also. Then I started with the SS Noise editing and a couple times quiting Mach, SS didn't unload the firmware and had to be unplugged/plugged. Got the noise number where the home worked pretty good, but then the button script won't work anymore!! I edited all the stuff out except for the original DoButton calls. Edited back in the move off stuff, won't work. Copied old HiddenScript.m1s file, which APPEARS to be where the button script is stored. Edited in again, won't run. I rebooted the computer, everything I could think of. The added text is in the editor window, but it won't run. What did I hose up now that the VB button script won't run? It homes fine without it, but I'd like the move off in there if possible, I like that!!
-
HiddenScript will just be the last code you messed with whether in the editor or a button, it will constantly change. Is it definitely the RefAll button script you are changing? ie you are clicking on that button when its flashing and not just editing via the editor on the Operator menu?
Hood
-
Yup, clicking on the blinking button. The text is in there, it just doesn't run. Where is the button script stored? I have Windows Home Server, I'll restore something if I know what to restore. I suppose I could just restore the entire Mach directory from last night's backup and see if that fixes it. Otherwise, what to do???
-
The button script is stored in the screenset itself, if its the standard screenset its called 1024.set
Hood
-
So if I restore 1024.set from last nights backup, I should be back to square one?
Why won't it run even though it shows that it's in there?
-
Check you have the script exactly as it was, if you dont have the
While IsMoving()
Sleep 10
Wend
before and after the Z move it probably wont work correctly.
Hood
-
I'm pretty sure it's right. I had it working fine with moving all three axes until I started messing with SS settings. I saved the text to a *.txt file when it was running and just pasted it back in after I broke it. I edited everything but the button calls out, saved, exited Mach, started, homed to test, edited it again, it won't run, but it homes fine. I'm off to restore 1024.set from last night and see if that fixes it.
-
When you get it working again copy the 1024.set to the desktop and rename it to ****.set (where **** is a name of your choice) then paste it back into the Mach3 folder. Then from the view menu in Mach choose load screens and browse and load that screen.
The reason for doing this is if you upgrade Mach it wont get overwritten like the standard screen would.
Hood
-
OK, will do, thanks for that tip. I restored, the old file had an original date of like 10/27/08, so hopefully that fixes it. I'll do your trick right away!!
I tried a blue screen set from machsupport today earlier, but didn't like it because the yellow text looked ducky at my res, 1280 x 1024. The regular Mach screen is OK for me.
Might not be back 'til tomorrow, normal life beckons!!
-
I restored 1024.set from backup, that didn't fix it, can't run button script but machine still homes all axes when pushing the button!
I restored the entire Mach3 directory from backup, still can't run button script.
Something must be hosed in Windows (Vista)? They ran fine yesterday. I don't know what else to try. Reinstall Mach3? Uninstall Mach3/Reinstall Mach3? Everything else seems to work fine.
-
It has to be running the button script or it woiuldnt home when you pressed the button, must just be a reason why it is ignoring the code moves, if you attach the screnset I will see if it works here.
Hood
-
OK, here it is. I still can't get it working!
-
Working fine here.
Put this in the button and see if you get the message box popping up before and after the Z move.
DoButton( 24 )
While IsMoving()
Sleep 10
Wend
MsgBox("Z about to move")
Code("G53G1F20Z-1.")
While IsMoving()
Sleep 10
Wend
MsgBox("Z has moved")
DoButton( 23 )
DoButton( 22 )
DoButton( 25 )
Hood
-
Yup, message box pops up, click OK, next message box pops up, finishes homing Y and X. Z does NOT move.
That's even stranger! Same code runs for you. So what's making Z not move?
I'll try X, see what happens. Maybe it's something with Z and the home switch and SS noise settings.
-
very strange indeed, maybe a reinstall of Mach over the top of itself would help.
Hood
-
I tried X, it won't move in the button script either.
I MDI'd G53F20G1Z-2. and that worked, so it's NOT G53!!
What version of Mach is best to use? I have latest lockdown. Should I try another, or just try and install over the top? I guess over the top first, then maybe something else.
Pretty strange that this worked fine yesterday. And it was while trying to tweak SS config for noise and having SS firmware not unload a couple times. When that happens you have to unplug the SS and the settings you did are NOT there, you need to do them over. I've learned that if I want to tweak SS, I quit Mach, restart, tweak SS, quit mach and watch for the green light to go out, then carry on. That SS could use a touch up, software/firmware wise, methinks!
Might I have a corrupt XML file, even tho' everything else seems to work? Or if I get a corrupt XML will other stuff be messed up? I had a bad XML last week trying to configure the Charge Pump on my C23. I'd set it, the numbers would move to a different field in Ports&Pins. Arturo from CNC4PC said I might have a corrupt XML, sure enough, that was it. Everything else seemed to be working.
-
It could be the VB interpreter or whatever its called that is messed up although I have never heard of that happening, reinstalling over the top of itself should sort that.
Dont think it can be the xml but suppose you never know, you could try one of the backups, operator menu then restore I think.
Hood
-
Reinstalled over the top, didn't fix anything, but...........get this, turn Soft Limits off it works just fine!!
So, what's that about? I'd prefer to leave soft limits ON always, so I don't forget. I do get a beep and a Soft Limit exceed or something when homing just after the Z hits the switch. No idea how Soft limits being on makes it NOT run the move code, but carry on and home Y and X.
I'll have to check numbers in soft limits and see if there's something obvious.
Is there VB code to turn soft limits OFF at the beginning of the routine and ON again at the end!!? Do you have Soft Limits On?
The mystery continues.
-
OK sounds like you have the softlimits set wrong, you should have X and Y min and Z max as Zero.
Hood
-
That fixed it! I was being safe and had my soft limits .1" off the switch. Somehow yesterday I must have had soft limits off and it worked then I somewhere along the line turned 'em back on and it wouldn't work. I never connected the two. Senior moment!
Homing works great now.
Thanks, Hood! No wonder you have 6900 posts, you're the MAN! Saving us retired guys from ourselves over and over.
-
LOL, well its sorted now so we are both happy :)
Hood
-
Hey Hood,
Get this. After working for several days, now the Z goes to home, stops and doesn't go up off the switch, so I have a limit engaged message. It seems as if it's either not overriding the switch, or it isn't backing off the switch. The servo motor does NOT backup in Z like it does in X/Y. In X/Y it hits the switch and backs up a little, in Z, it hits the switch, the motor doesn't reverse even a tiny bit, and I get the limit on message and the LED's are on on the diagnostic page. What might that be? Granted, the knee is heavy but counterbalanced with 2 200 Lb. gas springs, so it moves pretty easily. I'm mystified again!
-
Sounds like noise, your switch is being seen triggering momentarily then not again then againbeing seen etc, it will probably be too fast for the LED to be seen but Mach is picking it up. Try putting a value in the filtering for the home switches on the SS Config page.
Hood
-
I've put values in SS config for home switches from 0 to 1000, like 0, 2, 10, 100, 200, 300, 500, 1000, with no effect. Should I try something else?
-
no, its unlikely that it will help if you have gone that high :(
What kind of switches do you have? are they connected in series on all axis and going into one input or do you have seperate inputs for each axis?
Hood
-
Switch setup is CNC4PC C16. They are optical and are apparently connected in series. There is a wire going from the C16 X Home to CNC4PC C23 BOB Pin 11, another from Y Home to Pin 12, another from Z Home to Pin 13. Ports and Pins setup accordingly. This was working the other day just fine.
-
Only thing I can think of is to check carefully that there are no problems with the wiring to the BOB.
I think I might be tempted to remove the wire from Pin 13 and fit a mechanical On- Off switch in its place with enough wire so it can be operated by hand from your control panel, then do a RefAll and operate the switch to see if it seems to work correctly, no need to wait until the axis is near the end of travel when doing that so its a relatively safe way to proceed. If all works with that then it has to be a problem with the optos or wiring, if it still screws up then it is from BOB in the way.
Hood
-
OK, I'll try that.
One thing I KNOW is there is a physical LED on the C16 and a physical LED on Pin 13 on the BOB, and both of those are ON when this happens, as well as the yellow LED's in Mach on the diagnostics page for M3 Limits and Home. So the signal from the opto switch is making it to the BOB at least far enough to trigger it's LED indicator and trigger Mach enough to show its LED's!! Seems to me Mach either isn't over riding the switches, or not backing Z off the switch, which is what I SEEM to be seeing, the handwheel on Z does NOT backup a bit like X and Y do when homing and I swear it used to back up! How can it come off the switch if it doesn't back up?
-
Sorry was busy working when I read your post earlier and mis-read thinking you had said the LED was not on, but reading your last post and going back I see you had said the opposite.
Ok so it has to be some form of noise or bounce. What value do you have in the SS config for the home switch?
Hood
-
Like I said, I've tried everything, 0, 10, 100, 200, 300, 500, 1000. I'd be happy to try something else!!
-
If you have a high value in at the moment try something low.
Dont really know what else to suggest but has to be mach sees the switch active, starts the backoff, sees it close and then it opens again. This seems to be, from your description, happening so fast Mach doesnt even really back off. Cant think what else to suggest other than if its easy enough to do try swapping a limit from another axis onto the knee to see if its a problematic opto.
Hood
-
I just ran a manual test on mine on both X and Y axis, the Z is too long a reach. What I found is that the Y will retract indefinitely if I hold the switch ! The X will only do a bump and stop !
What I would like to know is this
What file is in control of the axis homing routine ?
How is it identified ?
could it have been corrupted by some influence ?
What do I look for and If it is a corruption how can this be prevented ?
I have tried the NON lockdown Mach's and then went back to the latest lockdown 3:42:20
I have also been searching for and trying probing files ! and may have created a situation in that way
So, Lets get off of the NOISE and take a look at the controlling files and see if maybe something is getting in the way here and corrupting things,
PLEASE ! ! ! !
-
I think it is done internally in the SS but Greg would be able to confirm that, maybe you should try downloading the plugin again.
Hood
-
As I reread my last post I got to thinking of the .XML and M1S files and am wondering about the hierarchy's involved with them. Mach has its own XML and then I run with the SMOOTHSTEPPER XML >But< there are other xml's as well that are still there with differant names of course. The files have internal calls to (I assume) specific files that are in their specific locations, etc. I think what I may do is to erase the whole folder and start from scratch but I really don't want to. This may clear up the issue, but, I don't know for sure exactly what file to save for setup, tools, wpo's etc. without saving garbage. I would like to start from scratch on the probing too but the darned things come from everywhere ! there is no one place for what works ! and it gets extremely confusing ! especially when the memory (mine) appears to be in need !
I am definitely going to wait on this till I have all the correct information and preferably make a printout of it for Memory sake. I don't recall any info anywhere how things inter relate within mach and wonder if something of an outline form sheet might be beneficial for such things as what we're dealing with now. If we could follow the logic to some extent we might be able to do a better job of it on our own without looking quite as stupid as we actually are. For instance, I have looked at some of the m1s files and noted one thing ! I can't tell what the identity is ! I read that we could study some of them and figure out some of our own routines but ! I haven't tried that yet tho as it may lead to horror, or an identity crisis.
Does any of this make sense, I'm having a difficult time trying to represent my intended thoughts.
I guess what it amounts to is, too many differant people putting neat little things together for us to try and we have no way of knowing the influences and int ereactions involved and will undoubtedly be getting into serious trouble !
I'm into radio controlled flying and what we commonly refer to is a "CRASH RECOVERY KIT" maybe what we need here is something for that purpose !
THANKS FOR LISTENING anyway
-
I'm with ya, Don! There HAS to be something here that causes this. Mine now won't back off the Z no matter what I do. The servo doesn't move, the handle doesn't move, nothing. X and Y back off just wonderfully, Z hits the switch and that's it, no backing off. I ain't buyin' the NOISE thing either. Noise doesn't seem to me to want to cause ONE thing over and over. Noise would be doing something else also.
I'll be looking forward to replies from others to see if there's some file or something that we can replace, change, delete and recreate, something, to fix stuff. I'm totally mystified by mine and have changed my homing to do Y then X, then Z, where it zeros the axis and sets it to homed, but won't back off the switch, giving a limit switch message after the overriding ends!!
-
Thosj I had to lie to my machine by .007" to comp for home limit. then the soft on the minus side works, not going to mess with the plus side tho. Someday this will get figured out. I have to agree tho that noise CAN & WILL interfer with things in a big way. I dealt with noise for a very long time till I found out that the "Made no sense at all" grounds made a lot of sense and made my system totally noise free as best I can tell.
I wonder tho if it couldn't be a time out deal since it is the last axis to home. That clunk sound is as if it starts to back out then gets cut short and the limit triggers.
I just reloaded the SS & Mach over the top of what I had, then got rid of the stuff I just don't use as in all the lathe & torch stuff as well the pendant & joystick stuff. I am going to just stick with the suplied probing routines tho just in case. I got rid of the ones in question.
-
Just a brief update on my homing issue with Z not backing off the switch. I've been conversing with Arturo Duncan of CNC4PC because most of my hardware came from him. He's mystified also. What I did lately was setup a new PC, XP instead of Vista, install Mach anew, get it configured enough to move/home. I get the exact same behavior. Z hits the switch, stops, homes Mach, sits on the switch (optical) not backing off. X and Y back off as expected.
So....
I've swapped Z Home to a different pin on C23 BOB to no effect.
I've changed Z to home Neg. after moving X/Y out of the way so it'd clear, so it's hitting a different physical switch, no effect!
Installed an entire new computer/Mach3 installation, no effect.
All this besides playing with SS noise settings all the way from 0 to 1000, physically grounding to a separate earth ground rod outside 8' in the ground everything I can think of. I HAVEN'T tried enclosing the machine in lead or wearing a tinfoil hat!!
Machine runs wonderfully for hours with no other sign of noise issues or anything other than this Z home problem!!
Before throwing my hands completely in the air I might try swapping Z and X optical switches but not changing pins where they go on C23 BOB, and changing pins in Mach. If the problem moves to X I have one thing, if it stays on Z, I have another. However, I'm not sure I know what to actually DO in either case!! My uneducated guess would be if it moves to X, it has to be the CNC4PC C16 home/limit board, if it stays on Z it has to be C23 BOB or SS..........or Mach somehow.
-
FWIW,
I also have intermittent homing issues with X and sometimes A while using the SS.
I am using these prox switches http://web5.automationdirect.com/adc/Shopping/Catalog/Sensors_-z-_Encoders/Inductive_Proximity_Sensors/Rectangular_(CR-z-DR-z-APS_Series)/12X27mm_(APS4_Series)/APS4-12M-E-D
The problem is only occasional.
My other problem of G00 moves only going at about 3IPM (when they should be going 100+IPM) is absolutely driving me nuts tho! >:(
-
I just woke up, but I read that several times and can't make sense of it (shakes head\rubs eyes).
I had a low ambience in the babble filtering, I approved a top ambience of 200 this morning and it seemed to accomplish no aberration at all in acclimation the problem. So far the best I could get this morning is .001" at 4khz and .017" at 2 khz and consistently the X arbor which of advance is the endure to home in the sequence.
________________
Thermostat (http://www.prothermostats.com/)
-
Before throwing my hands completely in the air I might try swapping Z and X optical switches but not changing pins where they go on C23 BOB, and changing pins in Mach. If the problem moves to X I have one thing, if it stays on Z, I have another. However, I'm not sure I know what to actually DO in either case!! My uneducated guess would be if it moves to X, it has to be the CNC4PC C16 home/limit board, if it stays on Z it has to be C23 BOB or SS..........or Mach somehow.
So....finally got 'round to swapping physical opto switches, Z for X, X for Z. Switched Ports & Pins to match. The problem went to X. It won't back off the switch on X now and it DOES back off Z just fine. In my mind, this makes the CNC4PC C16 the culprit. I consulted Arturo again and he's looking into it a bit before sending me another board/switches to try.
-
I could still be the switch. I would have physically moved the switches and rewired them so that switch 'X' was now in switch 'Z' position and wired to where switch 'Z' was on the BOB. That would tell you if it was the switch or the BOB. Right now you just know that it is either the switch or BOB.
-
Precisely what I DID.
Sorry for being unclear, but this is a CNC4PC C16 where the switches are hardwired to a board that in turn hooks to the bob. I've tested every other combo of this as mentioned further up the thread, and what I finally DID was physically move the switches, left the wiring the same from the C16 board to the bob, and told Mach3 it was opposite pins, X for Z. The problem moved to the X. So the only thing left for it to be, in my mind and Auturo's, is the C16 setup. It can be a switch, or the little board they all mount to that also contains other stuff, but it needs to be replaced as a unit. At least it does short of desoldering and stuff. As long as Arturo is willing to send me a new one, I'll do that.
-
But each switch is still wired to where it was on the C16 board, right? You moved the switches but left the wiring the same so you had to logiacally swap them in Mach.
-
But each switch is still wired to where it was on the C16 board, right? You moved the switches but left the wiring the same so you had to logiacally swap them in Mach.
Sorry again, as stated above, I did switch the Bob input pins previously with no change. And as far as the C16 goes (the C16 is NOT a bob, I have a C23 bob), those are hard wired so YES they're still wired to the same place on the C16, it's a unit. http://www.cnc4pc.com/Store/osc/product_info.php?cPath=29&products_id=183
-
A final note on my problem with the CNC4PC C16 and not backing off Z when homing for anyone finding this thread in a future search. Arturo of CNC4PC sent me a new C16 and the problem disappeared, so that was it. All axes backing off just fine now.
Awaiting Arturo's testing of my returned C16 to see if he can figure out how this happened.