Error 7 when attempting to Home

[WallClimber]

Hi there,

Just got my PMDX-422 board installed and up and running.  I can jog my 3 axis and have connected two proximity sensors (NPN) to pin 13 for homing my X axis and Y axis.  I see the input working on the diagnostics screen for X Home and Y Home.

When I click the Ref All Home button I get the following message and the machine automatically disables:

"Error 7 (Communication error) queuing HOME pkt for axis 'X' motor 'Slave 1' (id 3), aborting HOME cmd"

My setup is as follows:

Win 7 64bit
Mach4 version 4.2.0.2803 Licensed
PMDX-422 plugin version 0.33.159
PMDX-422 bootloader version 1.8.64
PMDX-422 firmware version 0.42.137

I have two motors on my X axis, motor 0 and motor 3.  I have set them up as motor 3 slaved.  This works as I am able to job around.
Other than trying to get this working I haven't set up any other things like limit switches yet so I am unsure whether this issue is limited to the homing command.

Any suggestions would be greatly appreciated.

Richard

[WallClimber]

Error log attached.

[WallClimber]

Just to follow up, this seems to be a general problem communicating with the board.  I have tried running some g-code and after a few seconds of running it will stop dead and not respond.  The board becomes disabled (DS2 LED off) and won't respond to mach4.  "ERROR: Could not disable the PMDX-SmartBOB-USB, error 'Communications Error''.
I then have to close Mach4, unplug the USB and re-plug to get it working again.

I have also tried JP2 (USB Shield Connection) in each different position.

Another thing to mention is that I'm running Windows natively (using Bootcamp) on a Mac Mini, not sure that this should make any difference to USB operation. 

[Jarhead]

Seems to be a common problem Same exact thing happens to me. They say they're working on it...

[Bob at PMDX]

Another thing to mention is that I'm running Windows natively (using Bootcamp) on a Mac Mini, not sure that this should make any difference to USB operation.

I cannot say if this is an issue or not, as I have no experience with Mac hardware.  I would guess not.  We do have at least one user who is running successfully under Bootcamp:
http://www.pmdx.com/PMDX-Forums/index.php?topic=114.msg378#msg378

Aside from that, you are seeing two different issues:

When I click the Ref All Home button I get the following message and the machine automatically disables:
"Error 7 (Communication error) queuing HOME pkt for axis 'X' motor 'Slave 1' (id 3), aborting HOME cmd"

Issue #1 - Homing.  There is a known race condition in the homing code.  I have a fix for this in testing for the next plug-in release.

Just to follow up, this seems to be a general problem communicating with the board.  I have tried running some g-code and after a few seconds of running it will stop dead and not respond.  The board becomes disabled (DS2 LED off) and won't respond to mach4.  "ERROR: Could not disable the PMDX-SmartBOB-USB, error 'Communications Error''.
I then have to close Mach4, unplug the USB and re-plug to get it working again.

Issue #2 - general USB communication problems.  I see that Steve forwarded email to me that you sent to him saying that replacing the USB cable solved this problem.  Is that the case?

Usually this kind of problem is caused by electrical interference from either the motor and motor power supply of the spindle (VFDs are particularly troublesome).  The general solutions involve re-routing any high current wiring away from the USB cables, the SmartBOB and any limit switch wiring.

Bob

[WallClimber]

Hi Bob,

Thanks for your reply - especially when I know you are busy with the trade show!

Yes I think with a combination of a different USB cable and moving things around a bit I seem to have avoided the communications errors - fingers crossed!  I ran a long routine of gcode and haven't had it stop again.

So yes, it looks like it's just the homing issue.  Fairly crucial but I can get by for the moment manually.

I wonder if I could ask a related question; do you have a timescale for supporting gantry squaring homing?  With the smoothstepper I had this set up with two proximity sensors, and it's quite important for me since using only one I often find a squaring discrepancy.

Thanks for your help.

[Bob at PMDX]

Hi Bob,
So yes, it looks like it's just the homing issue.  Fairly crucial but I can get by for the moment manually.

In case you haven't tried this yet, you should be able to go to the "Machine Diagnostics" screen and home one axis at a time.

I wonder if I could ask a related question; do you have a timescale for supporting gantry squaring homing?  With the smoothstepper I had this set up with two proximity sensors, and it's quite important for me since using only one I often find a squaring discrepancy.

Right now, no, other than "soon".  After the show we are going to review the "to do" list for the SmartBOB software and review priorities for the next couple of releases.

Bob

[WallClimber]

In case you haven't tried this yet, you should be able to go to the "Machine Diagnostics" screen and home one axis at a time.

Yes this works, but only as long as I don't try using the "Ref all home" button on the main screen during the same session.  If I do, I have to restart Mach4 to get the ref buttons on the "Machine Diagnostics" page to work.

Right now, no, other than "soon".  After the show we are going to review the "to do" list for the SmartBOB software and review priorities for the next couple of releases.

Great that it will be soon.  I will probably have to switch back to my Smoothstepper along with Mach3 in the meantime, as this is a crucial feature for me.

*Another* issue is that the "Go to Work Zero" button does nothing.  I have attached a log file generated when pressing the button.

Thanks

[Bob at PMDX]

Yes this works, but only as long as I don't try using the "Ref all home" button on the main screen during the same session.  If I do, I have to restart Mach4 to get the ref buttons on the "Machine Diagnostics" page to work.

Try opening one of the configuration dialogs (Configure->Mach... for example), then click on "OK" to close it.  That may reset things.

*Another* issue is that the "Go to Work Zero" button does nothing.  I have attached a log file generated when pressing the button.

Alas the log file you attached (the Mach4 diagnostic log) doesn't show me anything other than it entering a motion state then stopping.  To get more detailed information I need you to enable our plug-in's debug log, and then send me a "profile package".  The steps are described here:

http://www.pmdx.com/PMDX-Forums/index.php?topic=97.0

That message is also listed in the "FAQ - PMDX-SmartBOB Troubleshooting Tips" sticky message at the top of the SmartBOB message board.

After enabling the debug log, do whatever you need to do to make this problem appear (i.e. jog off of machine zero then click on "Goto Machine Zero").  Then disable the debug log and create the profile package as described in the link.  When you send me the package, also include a detailed description of what steps you took (i.e. if you jogged the machine, what coordinates did you jog to?).  You can post the package here or email it to me at bob at this domain.

Bob

[Jarhead]

I believe the Go to Work Zero button has been removed from Mach4, you must be using the old screen set if it is still showing. I believe the functionality is removed.

[Bob at PMDX]

I believe the Go to Work Zero button has been removed from Mach4, you must be using the old screen set if it is still showing. I believe the functionality is removed.

I see "Goto Work Zero" in Mach4 build 2803 in the wx4 and wx6 screen sets.  In the wxMach screen set the button reads as "Go to Zero".  As far as I can tell I haven't edited or modified the wx4 screen set.

Note that if you use our sample profile as the starting point for your profile, it will use the wxMach screen set by default.  That may (will?) change in a future release.

Bob

[WallClimber]

Thanks Jarhead.  Though I see "Go To Work Zero" on wx4 screenset and I am using Mach version 2803.  Should I be using a different screenset?

Ok so just to summarise, here are the problems I am currently experiencing:

1. "Reference All Axes (Home)" button causes the error "Unexpected homing request while Mach4 is disabled, ignoring" and also the error "Error 7 (Communication error) queuing HOME pkt for axis 'X' motor 'Slave 1' (id 3), aborting HOME cmd" flashes up briefly.

2. Go To Work Zero doesn't do anything.  Maybe I need to create my own button with a simple script for this.

3. A new problem I am having right now is that I can't run *some* gcode files.  One quite large (1.5Mb) file I was running happily an hour ago is now giving me the error "PMDX-SMARTBOB-USB DEVICE ERROR: SYSTEM ERROR (7): Motion Underrun"  When I press "Cycle Start Gcode" this message flashes up briefly and then the program seems to reset and disable the machine. 

I can email over logs shortly.

[Bob at PMDX]

Thanks Jarhead.  Though I see "Go To Work Zero" on wx4 screenset and I am using Mach version 2803.  Should I be using a different screenset?

The newer wx4 and wx6 screen sets call the button "Go To Work Zero" and the older wxMach screen set calls it "Go to zero".  Supposedly the same function however the scripts behind the buttons are slightly different but should have the same effect.  The wxMach screen set sends GCode (i.e. something like "G0 X0 Y0", by default leaving out the Z axis). The wx4 and wx6 screen sets call a function named GoToWorkZero(), which is defined in the screen load script to be:
        mc.mcCntlMdiExecute(inst, "G00 X0 Y0 A0")--Without Z moves
i.e. still sending GCode and by default leaving out the Z axis.  More than you wanted to know I'm sure.

1. "Reference All Axes (Home)" button causes the error "Unexpected homing request while Mach4 is disabled, ignoring" and also the error "Error 7 (Communication error) queuing HOME pkt for axis 'X' motor 'Slave 1' (id 3), aborting HOME cmd" flashes up briefly.

Fix for this is pending in next plug-in release.  Though what exactly do you mean by "flashes up briefly"?  Do you mean it shows up on the Mach4 status line at the bottom of the screen and is then replaced by something else (and you can see it again when you click on the "History" button)?

2. Go To Work Zero doesn't do anything.  Maybe I need to create my own button with a simple script for this.

This is what I am waiting for the debug log and profile package to look at.

3. A new problem I am having right now is that I can't run *some* gcode files.  One quite large (1.5Mb) file I was running happily an hour ago is now giving me the error "PMDX-SMARTBOB-USB DEVICE ERROR: SYSTEM ERROR (7): Motion Underrun"  When I press "Cycle Start Gcode" this message flashes up briefly and then the program seems to reset and disable the machine. 

Try increasing the SmartBOB's GCode buffer len and see if this has any effect.  Go to the Mach4 "Configure" menu and select "Plulg-ins". Click on the "Configure" button next to the PMDX SmartBOB.  When our config dialog appears, click no the "Performance Settings" tab.  The default for the GCode buffer len is 250 milliseconds.  Try increasing that to 500ms.  It that doesn't work, try 750ms.  If *THAT* doesn't work, then enable the debug log again and try to run the large GCode file.  When it fails, disable the debug log and either send me another profile package.

Bob

[WallClimber]

Try increasing the SmartBOB's GCode buffer len and see if this has any effect.

No unfortunately this didn't help.  It is happening with small files too so it doesn't seem to be related to the file size.  My error log is attached to the last post and I have emailed it over.  I have run one file perfectly fine a couple of times just now, and then next thing it won't run, giving the motion overrun error.  It doesn't make a difference if I restart Mach. 

[rae_gordon]

"PMDX-SMARTBOB-USB DEVICE ERROR: SYSTEM ERROR (7): Motion Underrun"

I am also getting this error on occasion.  It does not seem to  occur at the same instance while running my programs.  I restart the program and Re-Zero my AXIS since I am afraid that it is loosing its position when this occurs.  I have not tried to increase my buffer yet, but will do so.