Messages

196

SmartBOB controllers and dedicated accessories / Re: Limit switch recommendation

« on: January 02, 2016, 08:43:30 PM »

From the main Mach4 screen, go to the "Configure" menu and select "Mach...".  Then click on the "Input Signals" tab.  If you have a PMDX-422 or PMDX-410 and it is plugged into the PC and our plug-in is able to talk to it, then the A, B and C inputs should show up as "PinA", "PinB" and "PinC" in the drop-down list in "Input Name" column for any signal that has "SmartBOBUSB" selected in the "Device" column.  You should see "Pin10", "Pin11", "Pin12", "Pin13", "Pin15", "PinA", "PinB" and "PinC".

If you don't see them listed then all I can guess is that the plug-in thinks you have a PMDX-411 instead of a 410 or 422.  Go to the "Diagnostics" menu and select "PMDX-SmartBOB-USB".  That will show you what the plug-in thinks is connected to the PC.  You can also create a profile package and send it to me (either upload it here or email it to me at "bob" at this domain).  To create the profile package, go to the Mach4 "Help" menu and select "Support" and then "Create Profile Package".  Save the file somewhere that you can find it, then upload or email it.

Bob

197

General Discussion / MOVED: Estop Light Stays on

« on: December 31, 2015, 12:54:11 AM »

This topic has been moved to Parallel Port breakout boards, motherboards,  and dedicated accessories.

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

198

Parallel Port breakout boards, motherboards, and dedicated accessories / Re: Estop Light Stays on

« on: December 31, 2015, 12:53:55 AM »

You have the DIP switches "open" (or "off" as you mentioned).  As per the PMDX-126 User's Manual table 1 on page 10, this puts the PMDX-126 into "test mode - alternate pinouts".  As long as the PMDX-126 is in test mode it will force the EStop output to be active regardless of the state of the EStop input.  This informs the CNC software (Mach3, Macn4, LinuxCNC, etc.) that the PMDX-126 is not ready for normal operation.

Set all DIP switches to the "closed" position and press the TEST button (or cycle power to the board).  [edit] This puts the PMDX-126 into "Normal mode". [end edit] This is the first step in getting the PMDX-126 running (see section 2.2 in the User's Manual).

Bob

199

SmartBOB controllers and dedicated accessories / Re: Slaved axis problem

« on: December 20, 2015, 09:29:49 PM »

(6) Then I changed the step polarity to active low for all the motors. And powered back up and ran motors for 30 minutes and no problems at all.

Good news!  I would be curious to find out if the motors still work with 10us nd 5us step pulse widths keeping the step polarity "active low".  But it sounds like you are all set.

Bob

200

SmartBOB controllers and dedicated accessories / Re: Driver disabling 422

« on: December 20, 2015, 09:26:49 PM »

Jumper is removed, but main estop still doesn't do anything.

I'm not sure what you mean here.  What is "main estop"?  Do you mean that when you remove the factory installed jumper on the EStop input on the PMDX-422 that Mach4 remains enabled?  If that is what you mean, does the EStop indicator on the "Machine Diagnostics" tab show the EStop input changing state when you install/remove the EStop jumper?  If not, check your configuration (Configure -> Mach, then click on Output Signals tab and scroll down to the bottom and find "E-Stop" and make sure it is enabled (green check mark), and assigned to SmartBOBUSB and Pin10, with a red "X" in the "active low" column).

When I power on the drivers, the enabled light goes out. This happens when I have the ground connected on the limit switches " pins 11 12 13 "  which they are open anyway! So it shouldn't matter. However

If I leave the switches ungrounded, the enable light does stay on when drivers are powered up. Regardless, there is no movement when jogged. The dro does display movement.

Can you draw a wiring diagram and post it back here.  That will save us a lot of questions.  Include every wire you have connected to the PMDX-422 and exactly which terminal it is connected to.  Are you limit switches mechanical switches?

As for the motors not moving -  if the DROs are changing it means that Mach4 is talking to the PMDX-422 and that the PMDX-422 is generating step pulses.  The most common cause of motors not moving is having the step and direction signals swapped.  Go to the Mach4 "Configure" menu and select "Plugins..", then click on the "Configure" button on the PMDXSmartBOB line.  When the configuration dialog is displayed, click on the "Motor Config" tab verify whether the step signal pin-out (on pins 2,4,6,8 or pins 3,5,7,9) matches your actual wiring.

Bob

201

SmartBOB controllers and dedicated accessories / Re: Slaved axis problem

« on: December 17, 2015, 11:03:06 PM »

As far as the problem with no motors turning I had a while back in order to fix that I had to go into the pmdx config and change the step pulse width to 20 and the motors started working.It was set to 10.

That is very suspicious.  The KL-4030 data sheet says that it needs a minimum 1.2us pulse width and can hanclle pulse rates up to 100KHz (which implies a 5us pulse width at most).  If you have to set the SmartBOB to 20us pulse widths to get it to work, something isn't right.  This makes me wonder if there is something not quite right with the C30 board's output drivers, the C30 jumper settings or the wiring between the C30 and the KL-4030 drivers, or maybe even the step/dir outputs from the PMDX-411.

I've looked back the wiring diagram that you sent us back in early Nov.  It shows the C30 "COM" terminal going to the PUL+ and DIR+ terminals, and the step/dir terminals going to the PUL- and DIR- terminals.  It also shows that there are no series resistors in the step/dir wiring between the C30 and KL-4030 drivers.  Is this still your wiring configuration?

If so, please verify that the jumpers on the C30 board are set like this:
X6 (pins 2-9 select input or output) - Set to "OUT" (jumper pins 1-2)
X7 (+5V or GND for COM terminals) - Set to pins 2-3 for +5V
X4 (pins 2-9 pull up or pull down) - OPTIONAL: remove the jumper, turn it 90 degrees and place it ONLY on the center pin of the jumper.  I *think* this should make it so there is neither a pull-up or pull-down on pins 2-9.  Since jumper X6 is set for "OUT", these signals are (or should be) always driven and do not need pull-up or pull-down resistors.

And finally (for now), when running the tests from my previous post, do the following in place of step (5):

(NEW 5) In Mach4, disable Mach4 and go to the "Configure" menu and select "Plugins...".  Click on the "configure" button for the PMDXSmartBOB.  In our configuration dialog, click on the "Motor Config" tab and change the "STEP Polarity" to "Active Low" for all motors.  Click on "OK" until you are at the main Mach4 screen.  Enable Mach4 and then run the motors and see if one of them still fails.

Bob

202

SmartBOB controllers and dedicated accessories / Re: Slaved axis problem

« on: December 16, 2015, 10:49:53 PM »

First lets back up one step. Back in early Nov you were having trouble getting the motors to move even though the DROs were showing movement.  Did you get that resolved?

Presuming that you got the earlier problem resolved, has your system been running OK and then just recently started having one of the slaved motors stop working?  Or have you always had the issue with a motor stopping running?

Here is a sequence of tests to run.  Before running these tests, remove the motors from the machine and somehow label or tag the two X axis motors so you can tell them apart (for example, label them "1" and "2", or a piece of tape on the shaft of one of the motors, something other than "this motor was over there, and the other motor was over here" to identify the two motors).  Also somehow label the two KL-4030 drivers that are driving the two X axis motors.

Run these tests and let me know the results of each step.

(1) Using the current hardware and Mach4 config, run the two X axis motors until one of them fails.  Make a note of which motor failed, and which KL-4030 was driving that motor, and which 2 terminals on the C30 board were the step/dir signals for the motor that failed.

(2) Power down the motor drivers and swap the motor connectors for the two X axis motors.  For example, if "motor 1" was connected to KL-4030 #1, and "motor 2" to KL-4030 #2, then now "motor 1" connects to KL-4030 #2, and "motor 2" connects to KL-4030 #1.  Do not change anything else!  Turn on the motor power and run the motors until one of them fails.  Again make note of which motor, KL-4030 and C30 terminals were driving the motor that failed.

(3) Power off the system.  Swap the step/dir wires on the C30 board.  For example, if "motor 1" had step/dir on pins 2&3, and "motor 2" had step/dir on pins 4&5, change it so "motor 1" now uses pins 4&5, and "motor 2" now uses pins 2&3.  Do not change anything else, including Mach4 settings.  Power on the system and run the motors until one fails.  Again make note of which motor, KL-4030 and C30 terminals were driving the motor that failed.

(4) Try to run the motors again.  When one motor fails, place your fingers on the two KL-4030 drivers and see if you can tell a difference in temperature between the two.

(5) [EDIT: DO NOT DO THIS - based on info in following post that says you are already at 20us pulse width] In Mach4, disable Mach4 and go to the "Configure" menu and select "Plugins...".  Click on the "configure" button for the PMDXSmartBOB.  In our configuration dialog, click on the "Motor Config" tab and change the step pulse width to 10us instead of the 5us that I presume you have them set for.  Click on "OK" until you are at the main Mach4 screen.  Enable Mach4 and then run the motors and see if one of them still fails.

(6) Restore the previous step pulse width settings.

Bob

203

SmartBOB controllers and dedicated accessories / Re: Slaved axis problem

« on: December 15, 2015, 09:25:02 PM »

I have tried unpluging the motor plugs and swapping the motors and the problem goes to the other motor.So it looks like the motors are good and also the cable to the motor is good.

Do you mean you did this:
   MotorCableA to MotorA
   MotorCableB to MotorB, and MotorB stalls
then
   MotorCableA to MotorB
   MotorCableB to MotorA, and MotorA stalls
If so, then it still might be MotorCableB that is faulty.

BUT... I suspect that you need to change the direction of one of the two motors that drive the gantry.  Usually with gantry machines, the two motors on the gantry turn in opposite directions in order to move the gantry.   If the motors are set to turn in the same direction they will try to skew the gantry (though at this point BOTH motors should stall).  When the slave motor stops moving, does it keep making noise - like the motor is trying to turn but something is keeping the shaft from turning (this is called "cogging")?  If so, then you need to change the direction of the motor that is stalling.  You can change the motor direction in one of two places:

(1) Go to the "Configuration" menu and select "Mach...".  Then click on the "Motor Config" tab.  Select the motor that is stalling (probably the slave motor) and check the "Reverse" check box down next to the acceleration (or backlash - I'm not at a PC with Mach4 right now so this is from memory).

... or ...

(2) Go to the "Configuration" menu and select "Plugins".  Then click on the "configure" button on the PMDX-SmartBOB line.  In the plug-in config, click on the "Motor Config" tab and find the motor that is the slave motor and select "reverse" for that motor.

NOTE: The "reverse" setting in both of these places reflect the same configuration item.  If you change it in one place, that change will appear in the other place as well.

You should end up with the master motor having the opposite direction setting from the slave motor.

If that doesn't solve the problem, unmount the motors from the machine so they can spin freely without worrying about the gantry mechanism.  Then try to jog the X axis and see what happens.

Bob

204

Parallel Port breakout boards, motherboards, and dedicated accessories / Re: Pmdx 132 and pmdx 122 motion ceasing

« on: December 15, 2015, 09:04:39 AM »

We are going to need more information about how your have the PMDX boards wired and configured.  I'll start off with a couple of questions and some things to look at:

So you have 2 parallel ports in  your PC - one connected to the PMDX-132 and one connected to the PMDX-122, is that correct?

Do you have the PMDx-132 and 122 configured like figure 3 in the PMDX-132 manual, including the jumper settings?  If not, please describe (or post a drawing) of haw they are connected and configured.

If not, are the PMDX-132 and PMDX-122 configured to pay attention to the "charge pump" signal?  On the 132 this is jumper JP1, which can be either "not EStop" or "CP OK".  On the 122 this is jumper JP3 and can be either "not EStop/Fault" or "CP-OK and not EStop/Fault".

When the motion stops, look at the "outputs enabled" LEDs on both of the PMDX boards.  Are these LEDs on or off?

When the motion stops (and LinuxCNC still thinks it is outputting step pulses), do the inputs work (limit switches, EStop, etc.)?

And one last question - when the motion stops, can you change any of the outputs signals?  I don't know if LinuxCNC will allow you manual control of any output while it is running a GCode program, and I don't know what outputs you have defined- spindle on? coolant on?  Some external indicator light?  So this may not be possible to test.

Bob

205

SmartBOB controllers and dedicated accessories / Re: Default debug... any use for troubleshooting?

« on: December 04, 2015, 12:11:02 AM »

If the "debug log to file" was not enabled at the time of these errors (loosing communications and the red LED turning on), then the Mach4 profile package would not be of any help.

Bob

206

SmartBOB controllers and dedicated accessories / Re: Spindle Issues with SuperPID

« on: November 24, 2015, 12:17:57 AM »

ok, the Accel time took care of the turning on problem.

See my edits to the previous post that explains why the accel/decel delays were less than expected.

You already have my entire config there... you're still working on my error 7 issue.

Some people try making various changes to their configuration when trying to get something to work. I want to make sure you haven't changed any of the configuration since the version you sent me earlier - aside from changing the accel and decel times.

I have it wired exactly as shown on page 25 of the SuperPID manual, with the exception of another ground wire run to the ground pin of the 410.

Looking at your Mach4 config, it looks like you have the SuperPID "RUN" input connected to pin 5 on the G540 connector (which in turn is driven by pin 17 on the parallel port/SmartBOB).  And for now I have to presume that this is indeed the case, since you are able to stop the spindle by clicking on "Spindle CW" button.

The behavior you describe sounds like the RUN input on the SuperPID is not going high when you click on the "Stop" button in Mach4.  The SuperPID manual says that it limits the lower speeds to 5000 RPM minimum.   Which I interpret to mean that if the PWM goes away (zero volts as the control voltage), but the RUN input is still low, the SuperPID will keep the spindle running at the minimum speed.  Why this happens for the "Stop" button and not for the "Spindle CW" button I cannot yet explain.  And I cannot replicate this here in the lab.

So please run this test and send me the resulting log file:
(1) Exit Mach4 and delete any PMDX-SmartBOB-USB.log in your profile directory.

(2) Run Mach4 with your profile and Enable the debug log if it not already enabled in our plug-in configuration dialog (device = file, level = debug).

(3) Display the SmartBOB real-time display.  Go to the Diagnostics menu and select PMDXSmartBOB, then click on the real-time display.  You can move the real time display off the main Mach4 window it your screen has enough room.

(4) Start the spindle using the "Spindle CW" button.

(5) While the spindle is running, verify the real-time display shows pin 17 green and pin14 as yellow.  Measure the voltage between the RUN and GND terminals on the SuperPID (it should be close to zero volts)

(6) Click on the "Spindle CW" button again to halt the spindle, verify the real-time display shows pin 17 as red (pin 14 should be red or green but not yellow). Also measure the voltage between RUN and GND (it should be close to +5V).

(7) Open the GCode file that has been having trouble with the spindle.  Start running the file.  After the spindle is running, verify that the real-time display shows pin 17 as green and pin 14 as yellow.

(8) Click on the "Stop" button.  Verify that the real-time display shows pin 17 as red and pin 14 as red or green but not yellow.  When the spindle reaches its lowest RPM, measure the voltage from  RUN to GND on the SuperPID.

(8) Go to our plug-in configuration and restore the debug log setting to their defaults values.

(9) Exit Mach4 and send me the log file from your profile directory and tell me what your voltage measurements were.

Bob

207

SmartBOB controllers and dedicated accessories / Re: Spindle Issues with SuperPID

« on: November 22, 2015, 11:32:19 PM »

I can turn spindle on and off with the Spindle CW button.

Good.  When you turn on the spindle this way, does it take  the same amount of time to spin up to speed as it does when turned on via GCode?  How long does it take to spin up?

You can tell mach4 to delay after turning on or off the spindle before it executes the next line of GCode.  Go to the Configure menu and select "Mach...".  Then click on the "Spindle" tab.  Put non-zero values in the "Accel Time" and "Decel Time" columns for line "0" (zero), presuming that is the only spindle range  you are using.

*NOTE* Mach4, at least in build 2803, appears to delay for only HALF of the value in the accel or decel time fields.  For example, I put 10 seconds in the "Accel Time" and 5 seconds in "Decel Time.  I then ran this program:
   S5000 M3
   G0X2
   M5
   G0X0
After the M3 turned on the spindle, I saw a delay of approx 5 seconds, not the 10 that I had entered.  And after the M5 turned off the spindle, I saw a delay of about 2.5 seconds instead of 5.  So it appears that (for now) you need to set these delays to twice the actual spin up/down times.

***EDIT***
After talking to the Mach people, it turns out the Mach4 treats the accel and decel times as "accel time to max RPM" and "decel time from max RPM".  If the target speed is less than the max RPM, Mach4 estimates the time needed by:

    estimated accel/decel time = (target RPM /  max RPM) * accel/decel time

Since my max speed was 10,000 RPM and my target speed was 5,000 RPM, Mach4 used 1/2 of my given accel/decel times.
***END EDIT***

The other thing is the spindle won't turn off if I press the stop or reset button. It goes to the lowest RPM and stays running.

Yet when you stop it using the "Spindle CW" button it does stop entirely, correct?

In my experiments just now, the PMDX-410 is claims that it is turning off the PWM when the "Stop" button is pressed (to stop running a GCode file or MDI command sequence).  I can't verify that the PWM it actually turned off, that will have to wait until I'm in the office on Monday.

I need to know how you have the SuperPID wired to your G540.  And it would help to have your Mach4 profile. See:
     http://www.pmdx.com/PMDX-Forums/index.php?topic=74.msg224
in the "But an Even Better Way" section.  You can email it to me at bob at this domain.com.

Bob

208

SmartBOB controllers and dedicated accessories / Re: How to set up for Mach 4 to display RPM

« on: November 21, 2015, 11:25:21 PM »

Spindle RPM calculations from INDEX input happen in the device and/or plug-in, not in the Mach4 core.  This feature has not yet been implemented in the SmartBOB.  It is on our implementation list, though it may not make it into our next release.  If it doesn't, it will be in the following release.

Bob

209

General Discussion / Re: Smithy 1240 Linux to Mach3

« on: November 19, 2015, 11:39:08 PM »

First - I was mis-understood what the "AVO" terminal is.  It is an analog output terminal, not the analog ground reference.  Sorry about that.

If you connect VS to VC and still get only 3162 RPM on the spindle, then either some parameter in the VFD is not set properly or the VFD is defective.  First, with VS tied to VC, measure the voltage from VC to GND.  It should be VERY close to 10V.  Then review the VFD parameters.  I can't tell you how the VFD *should* be configured other than I presume it should match the Smithy document that you gave us a link to.  None of the "frequency" settings look (to me) any way related to 4000 RPM, but then I don't know if there is a non 1:1 pulley or gear system on the spindle, or an electronic "gear ratio" in the VFD.  And this goes beyond my knowledge of VFDs (at least without better explanations of the configuration parameters).

If/when you get the spindle up to 4000 RPM with VS tied to VC, then you can re-connect the PMDX-110 to the VC terminal and go through the PMDX-110 spindle speed calibrate process to get the trim pot set correctly.

Bob

210

General Discussion / Re: Smithy 1240 Linux to Mach3

« on: November 18, 2015, 05:34:28 PM »

I am about to exceed my knowledge of VFDs.  That said, if the PMDX-110 is outputting 9.82 or 9.89 volts to the VFD, AND presuming that the VFD is programmed so that 10V in results in 4000 RPM of the spindle (a big *if*), then you should be getting (9.8/10)*4000 = 3920 RPM.

From your graph it looks like you are getting somewhere around 3100 or 3200 RPM.  This is about 77% of 4000 RPM.  This makes me think that perhaps the VFD is not configured correctly, or there is something in the wiring between.

For kicks, command the spindle to 4000 RPM again in mach and measure the voltage AT THE VFD between the "VC" and "AV0" terminals.

hmmm... the VFD manual that you gave a link to is inconsistent in what it calls the analog input "common" terminal.  In section 3.5, the picture shows the terminal labeled "AV0" (as in Analog Voltage Zero, or analog ground).  But the below that diagram says "GND", which is also the name of the digital ground terminal next to FWD and RST.  I think this is a typo and in the analog input section of that table it should say "AV0".

So...  please verify that the "AV0" terminal on the VFD is connected to the pin 6 of J2 on the PMDX-110 board.  Also, generally speaking, the "AV0" and "GND" terminals on the VFD should NOT be connected together.  It kind of looks like they might be from your original wiring description of "GND - 2 wires violet and orange".

If you changed any wiring above, re-measure the voltage at the VFD between the "VC" and "AV0" terminals when commanded to 4000 RPM.

One final test: disconnect the wire from the VFD "VC" terminal and jumper the "VS" terminal to the "VC" terminal.  This will provide 10V from the VFD to the control input and *should* run the spindle at full speed.  See if that causes the spindle to run at 4000 RPM.  If not, and if "VS" to "AV0" measures 10V, then something is not correct in the VFD configuration.

Bob