PRS Alpha Missing Steps

[chubb]

Hi everyone,

I've been running into a constant issue with my PRS Alpha table for the past couple days.

When doing a complex cut job i've noticed the machine will seem to 'nudge' work in either the X or Y axis someway through the job. Once it nudges the work (usually by about 5-10mm) it continues cutting with that offset the rest of the job. So one part is in the right place (initial cuts) then the rest of the work is offset.

It is unpredictable and happens at different times in the same cut job in either axes.

Does anyone have any idea why this would happen? or have any suggestions as to how to overcome this issue?

Currently my only solution is to just repeat the cut on new material hoping that it works.

I've attached some photos of work that shows correctly set work on the left and work thats been nudged on the right (you can see in the bottom right the pattern has cutover the border line when it shouldn't.

Any comments, thought or opinions are welcome and appreciated :)

Thanks,


Mark

P.S.
I know it's not the machine missing steps since PRS has a feedback loop with the motors. :D

[bleeth]

This is almost always a grounding issue, particularly when it happens intermittently on different axis' and not in a constant spot.
Unfortunately, that can cause a hiccup, even in an Alpha.
Check all of your ground connections, etc. They do need maintenance periodically, just like the wires on a car battery (although you likely wouldn't see the buildup).

[Brady Watson]

Mark,
Please post a screenshot of your VR settings from SB3.

Also, are you running ASM911AA or ASM98AA-SG7.2 motors on your Alpha?

-B

[chubb]

This is almost always a grounding issue, particularly when it happens intermittently on different axis' and not in a constant spot.
Unfortunately, that can cause a hiccup, even in an Alpha.
Check all of your ground connections, etc. They do need maintenance periodically, just like the wires on a car battery (although you likely wouldn't see the buildup).

Hi Dave,

Admittedly, I have neglected my grounding cables. Having knocked a couple of them loose. I had my doubts about it being static though because of just how frequently it would occur. I didn't think the machine could be so susceptible. Nonetheless, I shall listen to the wiser and fix up all my grounding wires and give it another go :D



Mark,
Please post a screenshot of your VR settings from SB3.

Also, are you running ASM911AA or ASM98AA-SG7.2 motors on your Alpha?

-B

Hi Brady,

I've attached a clipping of my VR Settings and also a snapshot of one of the motor caps. I don't know if it makes a difference to the numbers, but the machine is set in millimetres (mm). I have ASM98AC-T7.2 motors on the Alpha.

Mark

[Brady Watson]

Mark,
Your VR looks fine @ default settings. What speeds were you cutting your parts? (MS values)

Also, what version of SB3 are you running? How long have you been running this version?

-B

[chubb]

Mark,
Your VR looks fine @ default settings. What speeds were you cutting your parts? (MS values)

Also, what version of SB3 are you running? How long have you been running this version?

-B

Hi Brady,

I was being pretty aggressive with my cut speeds.

I set the feed rate at 10 ips (plunge - 1.5 ips) and was relying (hoping) that the ramping would control the fury.

too much?

I'm running the latest controller software. Updated around the week it came out.


Mark

[Brady Watson]

I set the feed rate at 10 ips (plunge - 1.5 ips) and was relying (hoping) that the ramping would control the fury.

too much?


Yes.

Ramping will take care of many situations, but you cannot defy the laws of physics. This is like trying to make your car go 0-100 to 0 in the grocery store parking lot. Just ugly.

You may find this article (http://www.shopbotblog.com/index.php/2008/03/a-ramping-the-vr-command-and-how-to-tune-your-tool-for-maximum-performance/) helpful.

-B

[bleeth]

Looks like MDF and fairly shallow cuts. Your speed is high for that but if it is a good sharp bit it may work. Backing off to 6 is a good thing to do as well as lowering your plunge to .5 to 1.
In the meantime-The machine can be very susceptible. Get and keep it grounded correctly and then let us know how it goes.

[chubb]

Hi all,

So, it was a long day today trying all sorts of things to rectify the problem. To absolutely no avail. I've had to completely stop work on the machine because it's costing more to rectify mistakes than to have it running.

Here's what I tried doing:

1) Completely ground the machine.

2) Changed feedrate to 5ips and plunge to 0.5ips.

3) Split the cut pattern into 4 separate cut files.

4) Switched out the computer running the machine.

5) Gave the machine a complete service and check over.

No change.......well no good change;

I started getting "Unexpected Output" Faults and a weird new error I've never seen before: 'Shopbot No Longer Being Recognized", that forced the entire program to shut down.

Also, it messed up one of the jobs so bad I just let it run through to see how bad it would get. Nudged the work 3 times.

The slightly weird thing is that when it completed 'cutting' the work and jogged back home, it didn't jog back to 0,0 as it's meant to. it jogged back instead to the total amount it had gone off course by and it showed in the axes readings (not just by physically looking at the position of the spindle on the table).

I've attached a screen clip of the axes window showing the readings when it finished cutting. They should obviously read 0,0,25 but don't. The only thing that's accurate is the Z reading (haven't had any errors on that axis).

Does this help in sussing out what the problem might be?

I'm stumped.



Mark

[richards]

I believe that Brady is very politely telling you to slow down. The "offset" is a classic indication that the closed loop system cannot keep up with the physical forces expected. There is no cross-channel communication between axes when a motor stalls. In other words, the Y and Z axes do not slow down when the X-axis is overloaded. That can lead to an "offset".

I frequently had similar problems when I first used my PRT-Alpha in 2006. I ruined a lot of material before I slowed things down about 25%. When I slowed things down, the machine stopped wasting material.

Depending on the motor driver settings, the motor may stall for up to about 1/2-second before an alarm is sent and the system shuts down. If you're running 10-ips, that means that an axis can be as much as 5-inches "off" before the machine stops. If the driver is able to recapture those steps and recovers without sending an alarm, the other axes may may moved significantly while the problem was occurring. Nothing in the system recaptures the proper settings for all axes.

[chubb]

Hi Mike,

Dropped the speed down to 5ips and still had the same offset problem. Also tried one test cut at 3ips, and it started offsetting almost immediately so gave up on trying to lower it and stuck with 5ips.

Didn't know that there's no cross-channel comms between axes. Not sure whether the motor is stalling, is there someway to tell definitively tell if it's stalling? It's a very shallow cut with a new 90 deg bit. deepest cut is about 8mm, average cut is about half that. Also, reducing the speed hasn't reduced the amount it offsets by.


Mark

[Nate Zellmer]

Hi Mark,

Sorry to see you're continuing to have problems with this after the trouble-shooting you've done. The grounding and move speeds are certainly good spots to start when dealing with positional issues. I'm trying to work my mind around what led to the offset you pointed out at the end of the file. I've got a couple thoughts for the next step in identifying what would lead to it though.

1) Are you still using the USB hub that came with the tool? If that's going bad it could be a weak link in the communication chain. It's really intended to help older computer maintain adequate data rates, and on your newer computer with up to date software it's not needed.
2) If you have time while doing other tasks, try running an air cut of the file you encountered issues with. Turn off power to the spindle and dust collection systems and see if you're still off at the end of the cut.

Let us know what you see.

Nate Zellmer
ShopBot Tech Support

[chubb]

Hi Nate,

I'm just heading off back to the workshop to try what you've suggested. Should have an update in about an hour.

Mark

[bleeth]

Don't forget to get that grounding system hooked back up right!!

[bleeth]

Just saw your "laundry list" of things below that you have done and that it includes grounding. I have a couple new suggestions now (After you do what Nate wrote).

1. If the operating computer is networked and/or hooked up to the internet, take it off both. Then apply all "black viper" bare bones service modifications. If you have to have network, then carefully survey the steps so you don't disable this ability, but if hooked up to internet, don't ever go anywhere you are not completely sure of, and don't use it for e-mail. Run the network through a router and make sure your router has a proper firewall. Disable all automatic upgrades, screensavers, timed power control, and software update checks. I firmly believe that any computer that is running a Shopbot should be dedicated to that task and not used for other general needs. Any program running in the background can cause issues. Some of the worst are antivirus and update checkers. If your computer is dedicated than you don't need anti-virus, security shields, or updates.
2. If after doing this you are still having issues, try going back to the 3.6xx SB operating software (available from the SB website). Apparently, there were quite a few bugs with all previous 3.8xx and personally, in your position, I wouldn't use anything but a tried and true version and the newest 3.8 hasn't been field tested enough for my liking. I've been doing fine with 3.6 and also have a single head Alpha with spindle. One of the nice things about 3.6 is the easy ability to do a speed check on your comm speed. Make sure you get the right firmware in if you do change your Op software.

[chubb]

Hi all,

Just an update for anyone keeping up with the thread.

So I followed Nates advice and took off the hub and turned off the spindle.......


Didn't have any effect. Same issue occurred with the offsetting.

But once again the weirdness stepped in;

I had split the cut file into four parts. Now taking the first part as an example; it cut fine for two pieces previously then messed up and offset towards the end on the third. When I did the air cut as Nate suggested it actually did the exact same offset error as it did on the third pattern in the exact same place (so that kinda cancelled out the randomness of the error).

After a call to Nate to try get it figured out he suggested actually changing the cut file. I had to find all J3 commands and replace the 'J3' in the command line with 'M3'.

So did that and run air cut again for the first part and it worked absolutely fine :confused:

I'm not too sure what the difference made by changing it from a 'Jog' command to a 'Move' command but apparently sometimes the control software can get a bit fuddled if there are consecutive 'J3' commands and changing them to 'M3' seems to solve the offsetting issue.

Also noticed that after it cut the part it usually cuts properly, instead of jumping to the section which it offsets it actually cuts a completely different section correctly and goes through the rest of the cut file accurately. It seems that it skipped a whole section of the cutting file and jumped straight to the offset part towards the end and lost it's relative position during that fuddle. I hadn't noticed the missing cut pattern before, but looking at the third piece cut, it's obvious that there are some missing elements

Also, it slightly lengthens the time it takes to cut the file, but only by about 20%.

So at the moment, I could only test the cut as an air cut with the spindle off because it's 2am here :p but it seems to be cutting it properly with the switched out commands.

Will do a full test cut tomorrow after amending all 4 split parts of the cut file and see how it goes.

Will be sure to keep the thread update on how it goes.

Thanks so much to all who put in their 2 cents and helped eliminate a whole host of possible problems. It really helped, irrespective of whether it solved the problem or not.

Nate, thanks so much for all your help in solving the issue.


Just saw your "laundry list" of things below that you have done and that it includes grounding. I have a couple new suggestions now (After you do what Nate wrote).

1. If the operating computer is networked and/or hooked up to the internet, take it off both. Then apply all "black viper" bare bones service modifications. If you have to have network, then carefully survey the steps so you don't disable this ability, but if hooked up to internet, don't ever go anywhere you are not completely sure of, and don't use it for e-mail. Run the network through a router and make sure your router has a proper firewall. Disable all automatic upgrades, screensavers, timed power control, and software update checks. I firmly believe that any computer that is running a Shopbot should be dedicated to that task and not used for other general needs. Any program running in the background can cause issues. Some of the worst are antivirus and update checkers. If your computer is dedicated than you don't need anti-virus, security shields, or updates.
2. If after doing this you are still having issues, try going back to the 3.6xx SB operating software (available from the SB website). Apparently, there were quite a few bugs with all previous 3.8xx and personally, in your position, I wouldn't use anything but a tried and true version and the newest 3.8 hasn't been field tested enough for my liking. I've been doing fine with 3.6 and also have a single head Alpha with spindle. One of the nice things about 3.6 is the easy ability to do a speed check on your comm speed. Make sure you get the right firmware in if you do change your Op software.


Hi Dave,

All our machines run by computer are strictly off any network whatsoever (security e.t.c) :D

I was an inch away from downgrading the control software and firmware if I hadn't gotten the issue resolved soon. At the moment with the file tweaks it seems to run fine, but thats as an aircut with the spindle off. Tomorrow will be the real test when I amend all the files and do a complete test run in material.

Thanks Dave for helping and chiming in with suggestions. Learnt quite a bit of detailed stuff just from all the suggestions people gave and really appreciated all the feeback. It also helped narrow down what the problem could be and get it solved faster. I'm sure I'll now recognise any grounding or ramping issues in the future ;)



Yes.

Ramping will take care of many situations, but you cannot defy the laws of physics. This is like trying to make your car go 0-100 to 0 in the grocery store parking lot. Just ugly.

You may find this article (http://www.shopbotblog.com/index.php/2008/03/a-ramping-the-vr-command-and-how-to-tune-your-tool-for-maximum-performance/) helpful.

-B

Thanks Brady,

Will definitely give the article a thorough read just to get more familiar with ramping. Thanks for pointing it out.

Will keep thread updated with how it goes tomorrow.

Once again thank you all.


Mark

[Nate Zellmer]

While I'm not certain it's quite "problem solved" yet, I'm glad we've found a reasonable workaround to get you cutting. I look forward to hearing your results today.

[chubb]

Hi all,

Well, amended all the cut files to remove all 'J3' commands and replace with 'M3' for all four part files.

Did all my usual prep and started cutting the border pattern........ran through the cutting file without a single hiccup whatsoever. no issue. It cut accurately and with absolutely no offsets whatsoever. Cut four more border patterns without any issues. The only change was the time it took, which was an extra 20 minutes, well worth it for perfectly cut patterns.

Got a little brave and combined all the four file parts to run as a single file with the 'J3' command switched out, and it still ran through the cut file flawlessly.

Had some spare time at the end of the day so went back to the patterns that had previously given me the same issue with offsetting. Gave them the J3->M3 treatment and air cut them. They also went through without a problem.

Still can;t figure out why particular files were having this offset issue as I have cut files that are way more complex, take way more time with similar feed and plunge rates, and heavier cuts that didn't have the offset issues.

Would really like to try figure out what exactly was the problem and how the machine translated the cut file that resulted in offsets. Just for future reference and maybe prevention.

Thanks so much for everyones input.



While I'm not certain it's quite "problem solved" yet, I'm glad we've found a reasonable workaround to get you cutting. I look forward to hearing your results today.

True, this really was more than a workaround rather than a solution. But as long as I'm cutting, I'm happy :D

But, do we have any permanent solutions for this issue?

Thanks Nate.


Regards,


Mark

[jerry_stanek]

What is your jog speed set at?

[chubb]

What is your jog speed set at?

Hi Jerry,

Have my jog speed at 300mm/s (around 12ips).




Mark

[richards]

On my old PRT-Alpha, if I remember correctly, the JOG command enabled the stepper driver to change the number of steps per revolution from 10X to 1X (or 1X to 10X). The Alpha drivers could send two different steps per revolution 1X and 10X. I'm wondering if the underlying problem shown by changing the J3 command to a M3 command relates to the 1X vs the 10X step resolution and if that could be solved by changing the jog speeds/ramping?

[chubb]

Hi Mike,

Changing the jog speeds/ramping values was something I wanted to try and see how it pans out.

I haven't yet gotten the chance to test an unamended cutting file with the jog speeds or ramping speeds changed (still catching up on work that was delayed due to this issue). But I should be able to do a quick test tomorrow morning before we start work for the day.

At the moment we are just switching all J3 commands in the cut files with M3, to avoid any problems. Lengthens the time slightly, but losing 1/5th of cutting time becomes somewhat significant over the course of a day...week....month. So really wanna try anything that will get me back to using jog commands.

Will give it a shot and update tomorrow.

Mark

p.s.
Does anyone know of any articles/whitepapers/books that explain the underlying systems in a shopbot? I'm thinking it would be worth a read just to have a better understanding of how it works through and through.

[Brady Watson]

At the moment we are just switching all J3 commands in the cut files with M3, to avoid any problems. Lengthens the time slightly, but losing 1/5th of cutting time becomes somewhat significant over the course of a day...week....month. So really wanna try anything that will get me back to using jog commands.


Why are you doing this? Jog speeds should be fine @ 12IPS XY and 3 IPS Z, since the tool is up in the air moving to a new location to cut. Move Speeds should be pulled down to something more reasonable, as I mentioned before.

-B

[chubb]

Hi Brady,

As mentioned in the previous post, Post #16 on Page 2 . On the advice of Tech Support, we changed changed all the 'J3' commands to 'M3' commands. When we do this the file cuts without any offsets or errors.

Running the machine without this change in the commands results in errors and offsets. Generally, no one is quite sure why it's happening. But there are several plausible ideas floating around that I'm trying to work through.

Also, we already tried lowering the move speeds right down to 3IPS and it made no change whatsoever (Post #11). We still got E's and offsets.

The only values we haven't tried changing and seeing if they have any effect are the jog speeds and the ramping values. So it's worth a shot.

Until we can figure out what the gremlin is, just so that we can keep cutting without worrying about offsets, we are still making the J3->M3 changes to all cut files. It may take longer, but it's better than wasting material and even more time.


Mark

[ken_rychlik]

The Machine must have gotten out of square/adjustment/V rollers, motor distance to the rack, ect.... When I had my prs, keeping it tuned up and smooth running always needed attention. With the power off and the wires to the motors unplugged I would move each axis all the way over it's travel by hand. This showed me where adjustments were needed. Once I had everything moving smooth by hand, then I would plug the motors back in and the missing steps were gone.

The move speeds can overcome the troubles of things being out of adjustment, but at jog speeds they could not keep up. Changing the jog speeds will help, but fixing the issue would be better.

[Brady Watson]

Hmm...wondering if your step multiplier values under VU are correct & in turn, the switches on your drivers are in the correct positions.

-B

[gerryv]

I notice that you said you were running in metric. I think I recall a very recent discussion that Ted was involved in that indicated an issue with metric.

[chubb]

The Machine must have gotten out of square/adjustment/V rollers, motor distance to the rack, ect.... When I had my prs, keeping it tuned up and smooth running always needed attention. With the power off and the wires to the motors unplugged I would move each axis all the way over it's travel by hand. This showed me where adjustments were needed. Once I had everything moving smooth by hand, then I would plug the motors back in and the missing steps were gone.

The move speeds can overcome the troubles of things being out of adjustment, but at jog speeds they could not keep up. Changing the jog speeds will help, but fixing the issue would be better.

Hi Kenneth,

Haven't given the machine a detailed look over in that respect. Just did a quick check by eye and all seems to be well. But will try that out and see how it goes.

Thanks for the idea. Hoping anything will work at this point. Still getting the offset uptil now if I don't chane the 'J3' command.



Hmm...wondering if your step multiplier values under VU are correct & in turn, the switches on your drivers are in the correct positions.

-B


Hi Brady,

Just recently checked the VU's and they were all spot on. Driver switch positions are also correct.



I notice that you said you were running in metric. I think I recall a very recent discussion that Ted was involved in that indicated an issue with metric.


Hi Gerald,

Yup, that seemed to be the indication as well when I spoke to tech. That it might be an issue with the Actual "J3" command and how it's handled by metric machines when there are so many (especially one after the other). Had a file this week that was giving me the offset error when I didn't change the "J3" command. So ramped down the jog speed to match move speed and still got the error, so then switched out all the "J3" commands with "M3" (still at the same lowered speed) and didn't get any offset errors.

There's still no solution to this issue. Tough to predict when it will happen, so still doing the command switch-out for all jobs.

Dunno if tech is still trying to figure out what the problem may be, but haven't heard anything from their end on any ideas for a permanent solution. Might just have to wait for the next SB controller release and see if it solves the problem. Still trying to do tests to resolve it whenever I get the time, but it's a slow process and I'm running out of ideas.

If there's any progress, I'll keep the thread updated. Thanks for all the input guys. Still working on it and testing things out.

Mark

[ken_rychlik]

In the mean time it will be MUCH easier to change your post processor to have it put move commands instead of changing them one at a time.

[scottp55]

Mark, Almost posted yesterday, But don't know PRS Alplphas from shinola. Showing my ignorance but noticed 3.8.12 addressed some metric issues. Would any help?

[chubb]

In the mean time it will be MUCH easier to change your post processor to have it put move commands instead of changing them one at a time.

Hi Kenneth,

dunno how to change postprocessor and slightly cautious about doing so with my limited knowledge :(

I just use the SB Editor (Any text program will do) and do a 'Find....Replace with' search to switch out the commands. Does take more than a couple of seconds.


Thanks for the tip though. I just don't have the knowledge to amend PP's at the moment.



Mark, Almost posted yesterday, But don't know PRS Alplphas from shinola. Showing my ignorance but noticed 3.8.12 addressed some metric issues. Would any help?


Hi Scott,

Honestly, if you hadn't posted that, I wouldn't even have known there was a new SB Controller release. I'm still on 3.8.10 :eek:

Thanks for pointing that out. I'm impressed that there are such frequent updates. Shows that the guys at SB are pretty active with their development. I like that.

Will upgrade on monday and see how that goes. Fingers crossed.

Thanks again. Would have probably been another week or so before I realised there's a new SBC release.


Mark

[scottp55]

Mark, only noticed mm as I was reading the"improved spindle shutdown after comms lost" 3 times and wondering if there was anything else relevant. Upgrading today:)

[chubb]

Well, this is embarassing.

I thought I had already updated on this thread.

The issue has been resolved. It was a conversion with the control software it seems.

3.8.12 pretty much solved this issue. That being said, there were some remnants of it acting like it was out of position (some jerky "confused" gantry movement that was usually the precursor of it about to carve in the wrong place).

Since updating to 3.8.26, there hasn't been any issue whatsoever. Completely resolved.

Seems like it was just all a conversion issue within the firmware.

Really sorry I didn't update on this sooner. Really thought I had.

Mark

[Brady Watson]

Glad you got it resolved. Thanks for posting back to let us know how you made out. You never know who else might be in the same boat and just reading your solution could help him out.

-B