Lost communication errors

[moe19]

Ok I have a challenge that is not new to the forum but nothing I read seems to cover my issues. My Shopbot software is losing communication with the control box at random intervals. I just updated my computer to a DELL running windows XP PRo. I updated Shopbot software and loaded control box firmware. I turned off the antivirus software and any other "self updating" software. If I go back to old computer using serial/serial connection I have no problems. It seems as though something is goofin with my USB port/adapter. Does anybody have any ideas? I have talked with Frank at SHopbot for a couple of days and tried everything suggested but I am having no luck correcting the problem. He thinks electrical interference but I have nothing but the shopbot in the building and the old computer works fine with the control box. IS there in the USb drivers or port settings that stops communication briefly?? Thecommunication is lost briefly but of course long enough to stop the tool and possible ruining the production run.

[harryball]

First, go back to shopbot software v .27 and not .29. I've been running with no trouble until I moved to .29

There will be another post shortly about my problems with .29.

[steve4460]

shopbot ver..30 is released .
check it out.

[paco]

I would highly recommend re-installing Windows CLEAN AND LEAN. 'Add and remove Programs' should look empty. 'msconfig' (run command) 'startup' tab should appear almost empty too.
Now, I know that re-installing Windows """can""" be a pain but just think that this computer is controlling the tool that machine expen$ive material...
It might not fix EVERY communication lost but I believe SB support is working on it. Let them know when it happen and how it happen (what you did when it happen) so they have something to work on. If anyhow you can duplicate the problem, let them know about the steps that lead to the problem.
I'm still on 3.4.27 and I can loose com. when I trigger a limit switch on K mode 1 out of 3 tests. Since I know, I can avoid it. 1 out of three times, I will loose position too! That's why I need perfect reference on some projects...

From your post, sound like even PRO isn't totally 100% reliable regarding this issue...?!

[moe19]

I am on version .27 right now. The old machine was working on v .15. I do have a lot in the startup menu. I tried to remove everything that I know I don't need but I don't know what every program is and if it is needed. How do you reinstall lean and clean? The lost comm errors come after 20 min or one minute with no pattern.
Does anybody know is there is a port setting that will "keep the port alive." Is it possible that it goes to sleep and doesn't respond when control box accesses it or is it more likely that another program is trying to access the port and interupts transmission? Can the port be 100% given to one application? Using Win 98 and the serial to serial connection I never once had a lost comm error.

[moe19]

also I can lose communication when the tool is running or if it is idle. Makes no difference.

[fleinbach]

Monte,

When Poco says "clean and lean" above. He is referring to re-installing Windows with minimal programs. Windows installs a lot of basic programs that most people may need in everyday computing. None of these programs are necessary when running the Shopbot. In fact, they can actually cause problems when Windows uses processing power to run one of them, while the shop but is running. First it is advisable to install a fresh new copy of Windows. Then go to add/remove Windows components. Here you can remove all the unnecessary programs that Windows installs and are not needed to run the Shopbot. These include accessories and utilities, Windows media player, online services, Windows Explorer, Outlook express, and anything else not necessary to run the shopbot. You will also need to turn off all screensavers and power management.
There are other things that can be taken out but these are probably the most important.

[dvanr]

http://www.talkshopbot.com/forum/messages/312/15479.html#POST41269

some more info

[harryball]

"shopbot ver..30 is released .
check it out."

Nahh, don't think so, I'm going to keep running .27 for awhile, too much to do. I'm not seeing any misbehavior from it, it's doing what I need done. I've already created one really expensive piece of firewood with .29, I don't need another one. I'll wait until it's been out a while and I have a slack I'm willing to fill with testing.

Robert

[paco]

28-29-30 seem all to address the implementation of the new G4 PRT upgrade reading the release notes.

PAco

8-/

[Brady Watson]

Hey pipe down Pogo!!! LOL!!!


Paco is right...there are special behind the scenes things that those versions address specifically for the 4G PRT. Do NOT run anything prior to 3.4.27 using the 4G setup.

-B

[beacon14]

I had similar repetitive lost comm problems which I attributed to an old, junked up computer, however when I brought the computer in to be upgraded I found out the memory was "bad". (I confirmed that was true by sending the memory card to the manufacturer, who replaced it under warranty).

Since changing to a "lean and mean" machine several months ago I can count on one hand the lost comm errors.

I set up the old, upgraded computer next to the ShopBot computer - now I can see a display of the CAD file that I'm cutting, or work on the next toolpath while babysitting the 'bot.

[thecustomsignshop]

Had a similar issue. Was a bad (failing) ground wire in the serial to USB connector in my Alpha.

Replaced the adapter, all is good again.

[moe19]

OK Here is the deal. I have my old win98 466MHz processer running side by side with the new 3400 Mhz amd running win xp Pro. I am using the usb/serial adapter on both. The old system works without any comm errors. The new system loses connection every 4-12 minutes whether the tool is in motion or not. I thought I found the issue inthe port settings because the new machine had different setting "hardware" turned off. I have reinstalled the drivers. I have removed almost every program and removed everything in the startup. I have shielded the computers with metal from any electrical interference. Everything is exactly the same except the windows version and of course the procesing speed which doesn't figure into much I don't think. Yhe old computer is still running all other programs in startup and running antivirus etc. It stills seems as though the software communication between win XP (ports) and shopbot control software (or firmware) are having problems. Doesn't this make the most sense with scenario described? Anybody have any ideas to try?

[bcammack]

I would turn all power management settings in the new one's OS to "off".

[moe19]

done that as well

[dvanr]

Monte

when you switch between the two computers do you change the firmware on the control box as well?

Your running v.15 on the old and v.27 on the new.

One other thing we use a lot of Dell boxes and they have a bit of a record with the their power supplies being noisy (RF) .Anyway you can beg borrow or ... a power supply from another manufacturer to swap out with the Dell one? (just to test)

[ted]

[This was a very puzzling/troubling problem for us, so Monte was willing to send us his computer to check it out. Here's the report.]

Hi Monte,

Your computer is on the way back to you. Hope you don’t mind if I also share this report with the Forum, since there seems to have been quite an interest here.

Computer arrived shortly after you shipped it. I only wish that I had warned you that it needed to be packed so that it could survive a 10ft drop. Fortunately, it still works ...

As you reported, when hooked up to a PRT Control Box using the USB interface, after about 30min, whether it was running a file or just sitting idle, it would report a communication problem. Also, as you reported, the computer was clean of any obviously interfering software, all suspend and hibernate functions were correctly turned off, and the USB driver for ShopBot was correctly loaded.

We put a monitor on the USB I/O so that we could observe and log what was going on. At the time-point of the communication problem, the PC failed to detect returned bytes (a message) from the Control Box. The failure had the appearance that the USB hub or controller in the PC had gone into a suspend/power-save mode. It was possible to immediately restore communication by moving the mouse and just clicking ‘continue’.

To try and figure out why the problem was happening, we again confirmed that all known suspend features were disabled (including the settings for each individual USB hub in the PC). We noticed that if we maintained occasional activity on the mouse or keyboard, the problem did not seem to happen. This latter also suggested some problem with management of the suspend features of the USB host controllers in the PC. [A little research revealed that earlier AMD Athlon processors had USB, suspend-management issues; but we found no indication that the problem still exists with current Athons or XP.]

So we looked at the organization of the USB connections in the computer a little closer. For those following along, you can do this for your own system by:

1) Going to the Device Manager, and changing the default View to “Device by Connection” (See Screenshot 1).


3888

2) Then expand the entries “Advanced Connection Entry”, then the “Microsoft ACPI-Compliant System”, then the “PCI bus” (see Screenshot 2).


3889

Now you can see the layout of the USB Controllers and Hubs by the little USB (pitch fork) icons.

You’ll notice there are several listing for USB Host controllers. You can expand each of these to a view of the layout for specific device connections in your USB system. (see Screenshot 3).


3890

These first views are all from a Dell desktop (Optiplex GX620). Note that the mouse goes to one controller and hub, the keyboard to another hub, and the ATEN-USB (ShopBot) to another hub. This is the way the USB layout also looks on my laptop computer.

On Monte’s Dell desktop computer (Dimension E521) the situation was a little different. There was only one standard controller and hub (this is a USB 1.1, “full speed” type) and all the USB devices were assigned to the single hub (see Screenshot 4).


3891

Theoretically, having all the devices on the same controller limits bandwidth, but there still should have been plenty of resources for ShopBot to work correctly (and it did except for that brief problem at ~30 min). But assuming that there was something about the particular hub/controller that was not working right, our idea was to get the ShopBot USB device onto another one. Since, this computer did show a USB2 controller being available (the Enhanced Host Controller), we plugged an external USB2 hub into one of the slots and the ShopBot cable into it. This hub, because it was a USB 2.0 device, was assigned to the other ( USB2) controller and ShopBot now had a new communications path of its own (see Screenshot 5). When we now tested it, it ran ShopBot fine for days without problem.


3892

In addition to allowing us to get around being connected to a hub that did not seem to be working right, one of the advantages of using this USB2 hub approach is that it allows us to make sure that there is always plenty of bandwidth for ShopBot. The ShopBot USB is only a 1.1 device, but having it on a 2.0 path, basically guarantees that data gets to the final attachment node at the most efficient speed (as long as there are only USB2 hubs along the path). The USB2 hub is a smart device (compared to the 1.1 hub which is just a repeater) and is much more efficient at distributing data.

Whether Monte’s specific computer has a defective USB controller/hub, or whether this is a problem with that general type of mother board we don’t know. We did test a 1.1 hub with mouse, keyboard, and ShopBot USB attached on another computer and found no problems resulting from having several devices attached to the same 1.1 hub.

Finally, before we sent his computer back to him, we installed a USB2 card in one of the slots of the PC, so that Monte does not have to worry about attaching a hub, etc. This creates the same new path to the ShopBot USB. In the end, this was a $20 solution to a problem that considerably vexed many of us. It was, nonetheless, an instructive exercise in showing how straightforward it can be to create a new, high-bandwidth, communications path from PC to tool.

Ted Hall, ShopBot Tools

[moe19]

as always you guys are the best. thanks for all the efforts. I look forward to COMM-error free shopbotting.

[ted]

PS ... for those who noticed, I reversed the last 2 screen shots up above. Sorry. -Ted