Odd behavior today...

[harryball]

I've just had a day of very odd behavior from the bot. I'm still running v.27 with no changes... the only change I've made is I finally installed the new relays last Friday and today is the first real day of use.

Things started OK and the bot behaved normally even with key movements.

I don't claim to understand why but...

A. the gantry jumped the track while running a file I've run a few dozen times before. It lost communication with the PC as well right when it happened. I checked everything I could think of and placed the gantry back on the track, the gantry ran the remainder of the day seemingly fine.

B. After the track jump and I reconnected to the PC the SB3 software locked up. I got some undefined variable error. So I rebooted. When I ran the software again it loaded slow but then seemed normal. Closing and reopening appeared normal, it was not load slow again.

C. the move keys in the keypad the bot now ramp up and down instead of move/don't move. It exhibits the same behavior it had when running v.29 over a month ago. It's annoying if you are trying to zero on a mark and I noticed it right away. It was behaving normally before the incident.

C. I was running a file at 6 ips and it seemed to be doing fine... suddenly it slowed down and looked like it was running at about half speed. It finished the file that way. This was the second time today I'd cut the same file. It's as if it went from 6 to 3 ips on it's own and stayed.

D. I was cutting roosting grooves at 12 ips... things started off ok but then the bot slowed down then sped back up... then down again and finished the file.

E. I resurfaced my table just this morning. This aftertoon I zero'd Z on the table normally and cut my files. The further down the table the deeper it cuts. By the time it finished it was a good .04 or so into the table.

It behaves VERY much like when I ran v.29... except in v.29 it raised Z no lowered. I did Help - About to verify I was running .27, I am.

I ran it about an hour or so after the relay change and it worked fine. I can't imagine that has anything to do with it.

I'm not sure what to check and other than the move key behavior the speed changes are hard to reproduce.

Any ideas?

Robert

[bill.young]

This is a completely un-educated guess but since it worked fine before the relay was changed, could something...maybe a cable or some other connection...have been knocked partway loose when the relay was installed, so that it's making an intermittent connection?

Bill

[harryball]

I'm willing to guess at anything right now... I just finished probing the depths of the control box, every little connection I could get at removed and reconnected. Nothing seemed wrong. I cleaned it out well with a vac, not that it needed it, but maybe a small piece of broken wire end or something was in there.

I'm going over every nut and bolt on the bot too. I've finished the Ycar and gantry. Nothing loose, all looked good, still square etc...

I'm going to reload v.27 and reinstall the firmware as well.

I don't like odd behavior, I like Working or On Fire, much easier to diagnose that way. :-)

Is there a "safety" or fall back code or anything in the bot controller? i.e. if the firmware malfunctions is there a default firmware that loads?

Is there ever a possibility that a software error could upload new firmware without me knowing? That one time it took a while to start the software... I've been wondering what it was doing.

Robert

[Brady Watson]

Robert,
I would go back to v26. I know what you mean about the keypad overshooting...It's a glitch that has been reported & should be cleared up in the next version.

While testing a beta a few weeks ago, I went in to get a drink while the bot was running the same file I had been running all day. I came out & the gantry was off the rails and the collet nut was smearing itself into 1" PVC sheet...I thought for sure it was that beta's fault!!! But...upon further inspection, I had forgotten to put a hold down screw in one spot, the part moved, walked up the bit and wedged itself agsinst the center leg of the table...my machine has so much torque that it doesn't stop unless there is a brick wall in front of it...and with no other place to go, it came off of the tracks. And once again...it was my own fault! That was the 2nd time the gantry came off of the tracks since I've owned the tool...the 1st time I was screwing down things and the gantry beat me


-B

[fleinbach]

Robert,

I had somewhat of a similar experience of some of the things you mentioned above about two months ago, after thoroughly cleaning my shop. I know you said you rechecked all your connections, but did that include the USB cable. Since I knew that I had moved the cables around while cleaning I pushed on the USB cable to make sure it was in tight. When this did not fix the problem, and I was fairly sure it was the USB cable. I completely unplugged it at both ends and re-plugged it after which my problems went away.

Check out this thread I posted about preventing a derailment of the X car. This won't solve your problem but it will prevent the nuisance of having to get your X-car back on the rails. I have not had a derailment since making this modification a year and a half ago.

Derailed (http://www.talkshopbot.com/forum/show.cgi?tpc=28&post=25062#POST25062)

[harryball]

Everything is running ok except the keyboard moving behavior remains different. I completely reloaded the software and uploaded the firmware. I did clean the USB connection and reseat all connections.

I think I know why the car derailed. I suspect that the PC lost communication with the bot while jogging was ramping up to 25 ips. When that sudden stop occured it jumped track. That's my theory eventhough the PC didn't display an error until right after the car jumped. I think it's just a software lag.

I have not been plagued with lost communcation errors, only a handful since I've been running, most of those early on. In this case I'm going to accept the theory that I did or bumped something during the relay swap to cause the problem.

HOWEVER... I don't understand why the keyboard move characteristic has changed.

BEFORE: I pressed K and the keyboard move window opened. I pressed and held an arrow key and the bot would start moving, somewhere around 1 to 1.5 ips would be my guess. It would stay at that speed, no serious ramping. When I released the arrow key the bot would stop, there didn't seem to be any ramping, maybe a tiny bit but I could pretty much stop on a dot. Pressing X would change it to jog speeds with ramping.

AFTER: Now I press an arrow key and the bot ramps up to about what seems 2 to 2.5 ips. When I release the key it slows down to a stop with several inches of drift. I changed the move speeds and it does honor the new move speeds, but with significant ramping on start and stop. It's impossible to stop on a mark as I must release the arrow key an inch or so before my mark. Jogging seems to work the same. I've had to use fixed increment movements to gain control of positioning.

Any ideas on what would cause this change in behavoir and how to revert it back?

Robert

[Brady Watson]

Yes...that version is still cooking. I went back to v3.4.26. I recommend that you do the same until the latest & greatest has been fully tested & released. Even the beat 'drifts'...SB knows about this, as I was probably the one complaining the most about it.

Just re-install v26 & reload firmware via v26.

-B

[ckurak]

Brady,

I am having a problem with changing to and from metric inside a file with v27. (The control software is having problems with the speed settings and tries to set the metric speeds to Imperial settings). Until I can document the problem so I can talk about it more, I would like to install v26. However, I only have v25 saved.

Where can one find older versions? I am looking for PRT v26.

Charles

[fleinbach]

Charles
It is on the way, check your email

[harryball]

I reverted to v.26. After your post today I removed everything from the PC, deleted all the files, entire shopbot directory. Reloaded fresh and uploaded the firmware.

I'm still getting the keyboard overshoot behavior. I'll just live with it until the next version comes out. I hope that clears it up.

Robert

[Brady Watson]

Robert...Just for sniffs & giggles reload the firmware again...If I recall correctly I've had it 'not take' a few times when updating it.

-B

[ckurak]

Frank,

Thank you very much.

Charles

[ckurak]

Frank,

What you sent me was for a PRTAlpha. I have a standard PRT.

HOWEVER, I worked with the version you sent me in PREVIEW mode and still had the problem. So, I am guessing that both the PRT v26 and the PRTAlpha v26 have the same problem. So, I am back to v25 on my machine and the problem is gone.

I have a test case that shows the problem. I will start a new thread in the Troubleshooting Section of the forum to describe it.

Thanks again for your help.

Charles

[harryball]

I reloaded the firmware 3 times on v.26. The behavior is the same. It continues a long ramp down after using the keyboard move keys. I set the move speed down to 1 ips and it's tollerable though still harder to center over a specific spot.

I checked the diagnostics display, the firmware is listed as "130" I quit tinkering with it last night, later today I'm going to revert to v.25 and see what happens. I wouldn't be so annoyed except as Murphy would have it... I'm doing a small project that requires me to register my start point a few times. It was a small project with low odds of repeat work so I didn't design anything elaborate like a jig. I figured I'd just clamp it down, position and run, flip over, register and run.

Robert

[Brady Watson]

Robert,
2 things...

1) What are your VR settings?

2) Press the 'd' key when you are in keyboard mode. This will move the tool a fixed distance that YOU define in the keyboard fill-in sheet. You can access it by pressing K, then in the upper right corner, click on the yellow 'pad' icon. Change the default Fixed Distance .1 value to something a bit more useful, like .01. When you get into keyboard mode, press 'd' and every time you press an arrow it will incrementally move the tool that fixed distance that you specified. To get out of it, just hit Esc or d again. You can also click on the Fixed button with the mouse.

-B

[harryball]

Brady, everything is default (.4, 3D RAMP 100, Min dist to check .15) except Slow Corner Speed I set to 50. I have tried with the default 65.

I upgraded to the Beta code and ran an air cut using my bat house. Keyboard behavior was worse with a delay after pressing the key before the bot moved, then it was as if the bot was catching up. I noticed the Jogs were also slow even though I changed my jog speeds to 30ips. I timed it and would guess about 10 ips was the max jog speed. My bat house file reflected the slow down.

I downgraded to v.25 and alas and for reasons I don't know... it works correctly again. Keyboard moves began to behave as they should and when the gantry comes jogging at you at 30 ips you get the urge to jump out of the way again.

Robert

[Brady Watson]

Robert,
If you want to soften up your corner moves, reduce the slow corner speed to 35-45. If you are cutting at high speed. your 1:1 Alpha really needs the extra cushion, and it will reduce mechanical wear by reducing shock to the pinions & rack during a direction change.

Jog speed seems to be a matter of preferrence...I have reduced my jog speed to 15-20 IPS to save on wear an tear. A communication break or accidental e-stop hit @ 30 IPS is not pretty...

If you run into any bugs or issues with the beta software, be sure to send Support an e-mail (with Beta Software in the subject line) telling them what you found/discovered.

-B

[harryball]

Right now v.25 seems to be working correctly.

I'll drop the corner speed to 45 from 50. I hate to get it too slow. I guess it's a trade in pinion wear and project time.

I generally leave the jog speed to 20 or 25 ips. I rarely jog long distances and it really helps speed up the drilling portion of the file. The holes are all about 8" from each other at the longest point.

I've just begun experimenting with changing jog speeds and such by file rather than globally. This allows me to set it to 30 ips just before drilling begins and back to 20 for cutting etc... I anticipate running for long periods of time in starting in March and am taking the time now to tune for it.

Robert

[Brady Watson]

Robert,
If they are only 8" apart from each other...it's never hitting 30...or even 10 IPS for that matter due to accel & decel.

Try setting the slow corner speed down to something like 35 on a file that cuts 6 IPS or more, just to see how much smoother the corner transitions are. Tweaking ramps is something that few learn to do, and it's nice to see people progress to more advanced CNC 'thinking'.

FYI, you can also change configuration files & save them with your 'perfect drilling config' or 'perfect 3D config' and load them when you do that type of file. This will load in VR & other parameters specific to what you are doing...Rarely are 3D settings for instance, the same as v-carving settings...or even profile cutting settings.

-B

[jay_p]

I realize that Robert's problems seem to be related to 3.4.27 (alpha), but I am wondering if people are having problems with 3.4.30 (4g) as well?

Jay

[harryball]

Suddenly, while running v.25 I lost comm with the bot and when I re-established the same drift problem occured when making keyboard movements. I let go of the key and the bot continues to drift and ramp down to a stop... this time it hit the limit switch after I took my finger off the key a good 3" before the limit.

I re-upgraded to v.27, loaded the firmware, re-downgraded, re-firmwared... stood on one foot while shaking a rubber chicken over it and it didn't fix the problem.

What GIVES?? What is this? and why me? This is a downright pain in the rear. I don't understand what is changing causing the behavior change. The ONLY thing I've found consistent is a lost comm error before the change in behavior.

I now have to anticipate and release the move key well before I arrive at the location. However, if I press X and go to rapid speed it actually stops QUICKER than in normal mode.

Robert

[oscarg1971]

Those keyboard issues sound exactly like the issues I am having after I installed the PRTstandard V4g 3.4.30. It ramps also when I move it with the keys. -Oscar