Random motion and lost steps after upgrade

andypugh wrote:

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! )

Are you using the exact same config files, or did you re-create the config files?

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 sweet

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.

andypugh wrote:

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

as soon as i get back to the shop, i will give that a try!

ok, after another week of frustration and no success, i think i have finally isolated the problem, but i'm not sure whether or not it is something in the software or something that I'm doing.

tommylight wrote:

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:

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! as soon as i run the machine with G61 everything works bang on! now the problem is that G61 is not a good mode to run the jobs that i do because with lots of complex curves it is slow and jerky. now the $10k question is am i just doing something wrong? or am i missing a setting? this code ran just fine with 7.5, so did something change with the TP in 8? and when i say it runs fine, i mean suddenly the clouds parted and angels farted. what i set in the config happened in real life ! now i can run full on except for the fact that i am running a large format router in exact stop

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

Were you using G64 or G64Pn (n=some tolerance number such as 0.001)? The P number is very important with G64, with out it most machines will make a big mess of most code.