Random motion and lost steps after upgrade
It seems that everything was OK with the old hardware on 2.5 and the old PC.
You are now on new hardware, 2.8 and a new PC.
Were there any known-good combinations in the middle, for example new hardware with 2.5, old hardware with new PC?
Are you using the exact same config files, or did you re-create the config files?
Can we see your HAL files? I am half-expecting to see a badly-configured PID controlling your stepgens.
Please Log in or Create an account to join the conversation.
Just to bisect the problem:
Were there any known-good combinations in the middle, for example new hardware with 2.5, old hardware with new PC?
There wasn't really a "middle" so to speak I scavenged the original router for parts when i built this new version, and at the same time i added the second driver on the y. the original had dual y motors ran from one driver, now this one has dual y motors on dual drivers so that i could use the JA homing (which is freakin elegant btw!
![:woohoo: :woohoo:](/media/kunena/emoticons/w00t.png)
i was using my original configs, and the JA script converted them and without thinking i started modifying them. the only thing that really got changed was the scale values because i switched the drive mechanics a little between v1 and v2 and adding second joints to the y. on the side, is stepper conf going to get an update to make it a little easier to set up joints rather than pouring over config files trying to find a typo? that would be sweetAre you using the exact same config files, or did you re-create the config files?
This morning i went over everything with a fine tooth comb and verified the integrity of EVERYTHING. i ran a multimeter over every inch of the machine making sure that it was not an electrical problem (i once had a machine that a solder spike worked its way through the shrink wrap and it was causing the x axis to spaz every time the z axis when up)
once that was done i cleared everything and started from scratch with a fresh config generated from stepconf. i set up the y so that the signal was daisy chained between the drivers to get it to work. once that was set up and working, then i added the second joint and ran that for a few seconds. that is about all i had time to do before work, but so far there are no following errors yet.
my real problems begin though when i a job. it only affects the z and i can jog all day long, or manually run m1 commands with no problem, no steps lost, and no following errors. but as soon as i run code, that is where it goes bad. and its weird, because it is totally repeatable. i lose steps in the exact same spots and the exact(ish) number of steps each time and only on 1 axis. so far it it seems to work ok and as soon as i get off work i will give it another go.
Please Log in or Create an account to join the conversation.
One thing that you see when running G-code but not when jogging is multiple axes moving at the same time.
Perhaps the repeatable points where it all goes wrong are the points where all the axes are accelerating hard, taking a lot of current and overloading a marginal power supply.
Can you tell anything from the types of places that it goes wrong?
Please Log in or Create an account to join the conversation.
If the old configs worked, then they ought to have continued to work.
for the most part they do.
ok, after another 3 days of frustration, this is where i am at:
everything works spot on, except for the z. i have (at least i believe anyway) eliminated any hardware issues. i have used 3 different breakout boards, 4 different drivers, assigned the z pins to different axises and it always ends up the same. the z axis freaks out whenever i run a program and only during rapids.
Perhaps the repeatable points where it all goes wrong are the points where all the axes are accelerating hard, taking a lot of current and overloading a marginal power supply.
as for hardware, i am running the dreaded (i know, i know! but I'm very poor) tb6600 drivers (hy-div-268-5a) on a generic 5 axis breakout from a pci parallel port with a 24v 20a power supply which should be adequate. they are driving 3 nema23 425oz/in (1 x, 2y) and 1 nema23 239oz/in on the z, geared 2.4:1 on a 8mm/rev acme lead screw.
i understand the limitations of the system and know that it isn't going to perform on the level of a $100k industrial cnc mill, but i am on a VERY limited budget and i upgrade what i can when i can afford it. but..... with that said, these components have performed outstandingly for a long time without any problems. aside from changes in the machine design to address some rigidity issues and make it overall stronger and more accurate, the essential core components are unchanged.
Can you tell anything from the types of places that it goes wrong?
i will try and describe this as accurately as i can.
at least for the testing part, i am using the polar.ngc code for testing because it has a lot of relatively fast up and down movements in a nice compact area.
when the code first executes, it goes to 0,0,0 and then the z does this little double jump. its a quick up and down movement, and that its so fast that the z stalls on the upstroke, so i come down on average around 2mm below 0, then all is good until the next set (33ยบ drill line) when during the rapid (it only happens during the rapids in-between the code blocks) it will do another double jump, and so on.
what happens is that the z spins out of control and no matter how slow i run the code (speed override) or how i limit the acceleration and max speeds in the ini, it just ignores the speed limits and spins it out of control. during the rest of the program, everything works just fine. this happens regardless with or without a load. the only thing that I've done that seems to make a difference is when i change the ferror. when it is 0.05/0.01 all works fine until a rapid and then i get a following error and the more i set it (0.5/0.1 or 1.0/1.0) the greater the jump will be on the z, but the following errors stop.
i am at my wits end here and think i am missing something obvious. here are my config files if that helps
Please Log in or Create an account to join the conversation.
I wonder if the Z acceleration is actually too high? The other axes have a scale of 900 and an accel of 40, so that's 36,000 step-per-second motor accel. The Z-axis is nearly 61,000 steps per second. You could try changing the [JOINT_3] MAX_ACCELERATION to 5 and the STEPGEN_MAXACCEL to 6.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
- Posts: 18515
- Thank you received: 6184
setp stepgen.3.maxvel [JOINT_3]MAX_VELOCITY
to custom.hal
Attached is your config with that setting added.
Please Log in or Create an account to join the conversation.
Try adding setp stepgen.3.maxvel [JOINT_3]MAX_VELOCITY to custom.hal
i tried this to no avail. nothing i seem to do limits how fast my z accelerates. i have dialed it down til my z runs at just a crawl (literally 45s to plunge 10mm!) and on the rapids it spins out of control until it stalls. i know the z can handle some speed because i designed it to be fast for 2.5d carving (nothing worse than waiting on a machine capable of 300ipm+ with a slow z). in the stepperconf i can run it up and down over 3" until around 50ipm before it stalls just to give you an idea of what its capable of.
the ONLY thing that makes a difference is when i slow the machine down to around 10ipm or less and ONLY then will it behave differently, which is to say that it still speeds up at the end of rapids, BUT it doesn't accelerate so fast that it stalls.
anyway, i had some pulleys that came in from china that i was waiting on and so i switched them out and in the meantime i decided to at least calibrate the x and y while i was trying to figure out my z issues and that is when i stumbled on this. for calibration, i run a simple program that creates a 10mm ladder of cuts on each axis and then i can compare the expected vs actual and make quick adjustments to dial it in. when i was cutting in a scrap piece of mdf i noticed that my cuts looked wonky. the code is real simple:
( <-------------------------------- Engrave1 --------------------------------------> )
G17
M3 S1000
G0 X0.0 Y20.0
G0 Z2.0
G1 F400.0 Z-2.0
( <-- BEGIN CUT --> )
G1 F1500.0 Y0.0
( <-------------------------------- Engrave2 --------------------------------------> )
S1000
G0 Z10.0
G0 X13.17509 Y20.0
G0 Z2.0
G1 F400.0 Z-2.0
( <-- BEGIN CUT --> )
G1 F1500.0 Y0.0
the problem arises during this line - G1 F400.0 Z-2.0. what happens is that all is fine and as soon as the G1 Z runs the z feeds slowly and then the x/y axis starts to feed and i end up with a slopped entry when it was supposed to be a straight plunge. when it gets to the bottom, it overshoots by about 0.3mm and then backs off to the 2mm mark. this in itself is almost unnoticeable when you are doing a series of stepped cuts, but a disaster for 3d carving and the faster you go, the more pronounced the bounce is. also it does it on the way up; as soon as it reaches the top of its retract, it overshoots and then corrects (sometimes)
so i went back to my trusty polar.ngc to test again and it was running fine, so i started comparing code and thats when i found out that all of my problems start and end with G64!
![:angry: :angry:](/media/kunena/emoticons/angry.png)
![:woohoo: :woohoo:](/media/kunena/emoticons/w00t.png)
![:angry: :angry:](/media/kunena/emoticons/angry.png)
on a side note....
and speaking of large format router, i think mayhaps i should install a second estop on the other end because getting to one when you are on the other side of a 2M machine and stopping it before it rips itself apart is truly a test of agility. this stems from what i think might be possibly be a bug in the homing setup of 8. these routers are ran without a z home/limit because every job is a different thickness and different spoil boards etc, so i have it set where the z is automatically homed and i probe and home when i setup. worked great forever. BUUUUUUUUUUUTTTTTTTTTTTTTTTT........ when you use the keyboard to home, life gets interesting(ish) and sometimes you need to re-home an axis, so i always used the "home" button on my current axis. no problem. axis homes, all is well in the world. but now when you hit the home button this is what happens: x - fine. y - motor 1 homes, motor 2 twiddles thumbs. z - y motor 2 homes, z sits there insolently. do this on accidental purpose with a wireless keyboard on the back of the machine and just see how fast one suddenly becomes a sprinter! is this a bug? if so where do i report it? if not, do i have to the connections in axis or axisrc?
anyway, thanks for the patience and sorry for the novel, but i had a lot to get across!
-dex
Please Log in or Create an account to join the conversation.
- Todd Zuercher
-
- Away
- Platinum Member
-
- Posts: 4978
- Thank you received: 1377
Please Log in or Create an account to join the conversation.
when you use the keyboard to home, life gets interesting(ish) and sometimes you need to re-home an axis, so i always used the "home" button on my current axis. no problem. axis homes, all is well in the world. but now when you hit the home button this is what happens: x - fine. y - motor 1 homes, motor 2 twiddles thumbs. z - y motor 2 homes, z sits there insolently. do this on accidental purpose with a wireless keyboard on the back of the machine and just see how fast one suddenly becomes a sprinter! is this a bug?
Yes, that definitely does sound like a bug.
So, home-all works OK? But homing just Axis Y doesn't work? I can see how that problem might have crept in depending on whether Axis was reconfigured to understand joints-axes
Please Log in or Create an account to join the conversation.