Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Bob at PMDX

Pages: 1 ... 7 8 [9] 10 11 ... 25
121
Looks like a straight forward match to the PMDX-107:

PMDX-107       SX3
AGND             GND
AOUT              AVI
AREF               No connection
COM               GND
Fwd/Run         START/STOP
Rev/Dir          F/R

And you need to set the DIP switches on the PMDX-107.  I am presuming you have the PMDX-107 installed on a PMDX-126 and that your ARE using the charge pump signal on pin 17 (which we highly recommend).  Let me know if you are not using a charge pump signal.  See the PMDX-107's User's Manual section 4.1 to 4.5 for these DIP switch settings.

CONFIG1, CONFIG2:  both "off" (normal mode)
CONFIG3: "On" (relay contacts act as "run" and "direction")
CONFIG4: "Off" (require "charge pump OK")
SLOW: either setting, start with "Off" for fast filter response.
5V/10V: "Off" (0 to 10V analog output - SEE NOTE BELOW!!!)

NOTE: you may need to adjust pot W1 on the SX3 board when the PMDX-107 is outputting 10V to set the max RPM on your spindle.

For the Mach3 configuration see our app note AN001 (http://www.pmdx.com/AppNotes).

122
Yes, you can tie the "Disable" input on all of the G203V drivers together.  The 5V to drive the "Disable" input can come from the "L+5V" terminal on J12 or J13.  These connector shares the same ground as the step/direction outputs.**

** NOTE: Well, the "ground" that can appear on the step/dir "com" terminal is not actually ground, but ground through a buffer IC.  So when the step/dir common is set to "ground", it may actually be a 1/10th or two above the "Lgnd" on J12 or J13.  But that is OK as far as the G203V is concerned.

Bob

123
I did have to slow down the jog rate at 45% so the metal tab would not touch the sensor but other than that they worked great.
It sounds like you have the metal tab moving directly towards the prox switch, and with the higher jog speed the motion wouldn't stop before the tab ran into the prox switch.  Is that correct?

If so I would recommend if at all possible to reconfigure the prox switch mounting and/or the metal tab so that the metal tab passes across the face of the prox switch.  Less potential for damage to occur.
Quote
Should of purchased them the first time.
Spread the word my friend :-)

124
General Discussion / Re: Losing steps in Z
« on: April 16, 2016, 09:17:54 PM »
Have you sent your profile and sample file yet?  I haven't seen them yet.

125
General Discussion / Re: Losing steps in Z
« on: April 15, 2016, 10:49:52 AM »
Yes, that is what I meant.  If the SmartBOB were somehow missing motion info from the Mach motion planner, the actual position reported back to Mach4 would not match the commanded position.  So after your "G0 Z0" command, the DRO would have read some non-zero value.  Since the DRO *does* match the commanded position, that means that the SmartBOB believes it has generated all requested step pulses (see note below).

Changing the step pulse width to 20us changed (improved) the behavior but did not fix it.  That is baffling.  As was your earlier report that removing the SmartBOB from your chassis also improved but did not fix this issue.  There is something I'm missing here.

- Have you checked the X and Y axis to see if they also have this issue?
- Please send me a profile package, and if possible a GCode file that causes this problem (the smaller the better).
  You can post them to this forum topic or email them directly to me at bob at this domain.

NOTE: The PMDX-410 uses hardware inside the processor to generate the step pulses.  The hardware generates an interrupt every time it starts a pulse, and that interrupt increments or decrements the position value that is reported back to Mach4.  I guess it is hypothetically possible that the interrupt could be triggered yet the pulse not actually be generated.  Or the pulse be corrupted somehow.  But again, *if* that were happening I would expect it to affect both directions of travel.

Bob

126
General Discussion / Re: Losing steps in Z
« on: April 14, 2016, 11:13:26 AM »
Oops, yeah I didn't finish #2.  Danger of responding late at night.  If the Z axis ends up more positive, meaning higher up, that means that it is missing steps in the downward (negative) direction.  This is not the usual case for Z axis errors as the "up" direction is usually harder since up requires working against gravity.  Going down you have gravity helping.

Yes, you can change the step pulse width.  Go to our plug-in configuration dialog and click on the "Motor Config" tab.  You can select 5, 10 or 20 microsecond pulse widths.  According to the G540 documentation, 5us pulse width *should* be fine.  But it couldn't hurt to try 10 or even 20 (if your max velocity will allow that - the plug-in will warn you if not).

If the DRO shows the correct position according to the GCode, that means that the PMDX-410 is generating the proper step pattern.  Hmmm... or else the PMDX-410 it is somehow missing an equal number of positive and negative going steps.  But that wouldn't give you the physical position error you are seeing. 

You say you tried swapping motors, cables, etc.  Did you try using a different G540 motor output?  For example run the Z axis from what the G540 labels as the "Y" axis (and changing the axis mapping in Mach4 accordingly).

I am puzzled that  removing the PMDX-410 from the control cabinet changed (but didn't fix) the problem.  I'll have to think about that a bit.

Possible causes of the physical position error include:
- under powered motor (driving with too low a current setting), though again this usually manifests itself
  with the Z axis ending up lower than expected.
- motor voltage too low and/or step rate too high and the motor can't physically respond fast enough.
  I would expect this kind of problem to affect both directions of travel, unless the down motion is always
  faster (in the GCode) than the up motion.  And you said you tried lowering the max velocity, which
  should work around this issue *if* you lowered it enough (and how much is "enough" I can't say
  other than try 1/2 and 1/4 of your original velocities).
- Time between changes in the direction signal relative to step pulses (called setup and hold times).
  The G540 manual calls for 200 microseconds [EDIT: that should be NANO seconds] for setup and hold,
  which the SmartBOB devices should easily meet.  Unless you have an incredibly high acceleration
  and feed rate.  But again, I would expect
  that is this were the issue that it would manifest itself with a more random position error.

Of these possible causes, the last (setup/hold times) would be a SmartBOB issue, if that is an issue.  Try changing the step pulse width and swapping motor connections on the G540 (if you haven't already) and see if that changes anything.

127
General Discussion / Re: Losing steps in Z
« on: April 14, 2016, 01:18:16 AM »
(1) When this happens, does the Z axis DRO reflect the actual, incorrect, height (i.e. around +0.1)?  Or does the DRO reflect the the ideal position (i.e. 0.0, I presume)?

(2) If the Z axis ends up more positive that it should, that means that it is missing motion in the *negative* direction, not the positive direction.  Is positive Z motion going up (i.e. if Z is at zero and you enter "G0Z1" does the z axis move up or down)?  If so, the missing

(3) What version of Mach4 and SmartBOB plug-in are you running?

Eventually I may ask for a profile package and possibly a GCode file that exhibits this problem.  But not yet.

Bob

129
No (mostly). The mounting holes on the PMDX-424 are not connected to anything on the circuit board, so grounding them would not accomplish anything anyway.  Depending on your configuration and wiring, you *may* end up connecting the ground for the isolated inputs (J16 and J17) to the machine ground, which in turn may be connected to the earth ground.  And that is OK because those inputs (and their ground) are isolated from the rest of the PMDX-424 (i.e. processor and USB interface).  But under normal circumstances, none of the "common" or "ground" terminals on any of the other connectors (J7 to J13) should be connected to earth ground.

130
There are two ways that the PMDX-424 will support tandem axes (and eventually, gantry squaring):

(1) Using Master/Slave mapping in the standard Mach4 configuration "Axis Mapping" tab.  All SmartBOB devices support this method for tandem motors.  In this case, you assign two of the motors to a single axis as in the example in my previous post.  The Mach4 motion planner is then in charge of feeding our plug-in the motion data needed to keep the tandem motors moving in sync during jog and GCode moves.  During homing, the SmartBOB device is responsible for moving both motors in sync.  If you have a tandem axis plus two more (for a standard x/y/z gantry machine), this uses all 4 available motors from the SmartBOB.  The step and direction connections come from PMDX-424 connectors J7 (Motor0), J8 (Motor1), J9 (Motor2) and J10 (Motor3a).  No connections are made to J11 (Motor3b).  Or you can use a ribbon cable from J6 to a PMDX-134 as you are doing.  You may also use 2 each PMDX-133 boards.  In that case, you would mount the Gecko drivers in the following PMDX-133 positions.  PMDX-133 #1 is the board that is connected directly to the PMDX-424.  PMDX-133 #2 is the board that is daisy-chained to PMDX-133 #1.


PMDX-424 Motor     PMDX-133
Motor0                    PMDX-133 #1, Axis #1
Motor1                    PMDX-133 #1, Axis #2
Motor2                    PMDX-133 #1, Axis #3
Motor3a                  PMDX-133 #2, Axis #1
- - - - -                     PMDX-133 #2, Axis #2 - NOTHING CONNECTED HERE
- - - - -                     PMDX-133 #3, Axis #3 - NOTHING CONNECTED HERE

** OR **

(2) Use the PMDX-424's hardware cloning facility.  In the Mach4 configuration "Axis Mapping" tab, map "Motor3" as the "Master" on whichever axis is your gantry axis (the "X" axis in your case).  Do not assign any motor as a "Slave" motor for that axis.  Mach4 will have no knowledge that this is a tandem axis.  The PMDX-424 will ensure that the two motors move in sync with each other during all types of motion.  Wire the step and direction signals from J10 (Motor3a) and J11 (Motor3b) to the two motor drivers on your gantry (see NOTE #1 below).  This leaves 3 other motors available (Motor0, Motor1 and Motor2) for use as you see fit (perhaps 2 more linear axis plus a rotary axis, or tool changer motor, etc.).  This will NOT work with a PMDX-134 connected to the ribbon header at J6.  It *WILL* work with 2 each PMDX-133 boards connected in series to the J6 ribbon header.  In that case, you would mount the Gecko drivers in the following PMDX-133 positions.  PMDX-133 #1 is the board that is connected directly to the PMDX-424.  PMDX-133 #2 is the board that is daisy-chained to PMDX-133 #1.

PMDX-424 Motor     PMDX-133
Motor0                    PMDX-133 #1, Axis #1
Motor1                    PMDX-133 #1, Axis #2
Motor2                    PMDX-133 #1, Axis #3
- - - - -                     PMDX-133 #2, Axis #1 - NOTHING CONNECTED HERE
Motor3a                  PMDX-133 #2, Axis #2
Motor3b                  PMDX-133 #3, Axis #3

NOTE #1:   The PMDX-424 will move the Motor3b motor in the opposite direction as the Motor3a motor by inverting the direction signal.  If your gantry needs both motors to move in the SAME direction, you will have to re-wire the connections between the Motor3b motor driver and the motor itself to reverse that motor.  Swapping the 2 wires from one phase of the motor will accomplish that.

Bob

131
? Output Type : PNP NO
There's the problem.  The PMDX-424 is not compatible with PNP-style prox switches (see the PMDX-424 Quick Start Guide, section 4.12).  You will need to either replace your prox sensors with NPN-style ones (like we sell here http://pmdx.com/Prox-01), or buy a PMDX-105 (http://pmdx.com/PMDX-105) to interface 4 each PNP-style sensors to the PMDX-424.

Bob

132
When connected to a PMDX-134, the PMDX-424 motors map to the PMDX-134 positions as follows:

PMDX-424    PMDX-134
Motor0          J1 (Axis #1)
Motor1          J2 (Axis #2)
Motor2          J3 (Axis #3)
Motor3          J4 (Axis #4)

Yeah, we really shouldn't have called the connectors on the PMDX-134 "axis" as that confuses things when you have a tandem axis.  When using a PMDX-134, ignore the PMDX-424's "Motor3a" and "Motor3b" outputs and just consider them a single "Motor3" (which is how it appears in Mach4 anyway).

In the Mach4 Configure->Mach "Axis Mapping" tab you could for example map "Motor0" to the X axis master, "Motor1" to the X axis slave1, "Motor2" to the Y axis and "Motor3" to the Z axis.  But that is just an example - any mapping of Motor0 through Motor3 to the X master/slave, Y and Z would work just as well.

Bob

133
Still no luck, I did what you said, put a check mark on the Active Low for motor 0--, i also removed all other devices from the input singles.  do you think i may have bad sensors i tried two of them already.  Now what I get in the History line is (Mach halted due to X-- LIMIT switch active)
FYI I still get the same note in the history line even when i unplug the sensor from the PMDX 424 board. 
Might just og ahead and purchase new sensors from PMDX just to be on the safe side.
While I'd love to sell you a handful of prox sensors, lets back up a step or two and see what we can figure out with your existing sensors.

(1) Please let us know the manufacturer and model number of your prox switch.

(2) Connect one and only one prox sensor to the PMDX-424: blue wire to the "GND" terminal on J16 or J17, brown wire to the "+12U" terminal, and the black wire to the terminal labeled "1".  This should be how you already have the sensor wired, judging by the profile you posted.  But just to make sure.

(3) Power on the PMDX-424 and start Mach4.

(4) In Mach4, go to the "Diagnostics" menu (*not* the "Machine Diagnostics" tab), and select "PMDX SmartBOB-USB".  From our diagnostics dialog, click on the "Show Real-Time Input/Output Status" button.  Move the real-time window off to the side and close the diagnostics dialog.

(5) With no metal near the prox switch, record the state of the LED on the prox switch and the "Input 1" indicator in the real-time window - it should be either a dim red or bright green - crud! Not too helpful if you are red/green color blind.  Hopefully you can tell the difference in the brightness.  If not, a screen shot will help.

(6) Now put a piece of metal near the prox switch.  Again, record the state of the LED on the prox switch and the "Input 1" indicator in the real-time window.

Let me know what you observe.  If everything is working as I think it should, I expect that for step (5) the prox LED will be off and the "Input 1" indicator will be bright green.  And for step (6) the prox LED will be on and the "Input 1' indicator will be a dim red.

Bob

134
In general, any of the PMDX-424's inputs will work.  However, I would recommend using one of the 8 isolated inputs on connectors J16 and J17 (i.e. SmartBOB Input1 through Input8).  These provide extra protection "just in case", since the touch probe wiring goes over to the machine instead of, say, switches on a panel.

Bob

135
then i went to input signals and selected Motor 0-- and put a check mark on Mapping Enabled, SmaartBOBUSB in Device, and Input1 in Input Name. checked apply and then OK.  In the machine diagnostics screen the X-limit is colored red/yellow ( sorry I'm Color Blind) In the history line it says (limit switch X-- tripped!)
You need to check the "Active Low" column for the "Motor 0 --" input.  Your prox sensor grounds its output when it senses metal.  Now the indicator on the Mach4 Machine Diagnostics screen should turn on when there is metal at the sensor.

FYI - check the "active low" column for *any* input that is driven by the prox sensors (I see you have Motor 0 ++ mapped to pin 15, though not enabled).

Bob

Pages: 1 ... 7 8 [9] 10 11 ... 25