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 ... 15 16 [17] 18 19 ... 25
241
I am the lucky owner of a still fully functioning BOB :)

I can indeed verify that the relay is driven directly from the input thus requireing more than 50mA on the output...

Which one of the pmdx 104 and 105 should i buy? what are the differences (other than comparing specs) what use can i have for the pricier option?
Luck sometimes works in our favor!  The PMDX-104 will be easier to connect, though it is a bit more expensive.  With the PMDX-104, you can wire two of the pairs relay contacts between the DAQ-PWM's +5V and the two "enable" inputs.  With the PMDX-105, you will need to add a diode from each of the DAQ-PWM's enable inputs to the +5V terminal to protect the electronics on the PMDX-105.

Quote
The DAC PWM Does respond to Step/dir signals, do i nedd additional electronics to be safe?
I would think that these inputs would be OK to connect directly to the PMDX-126's outputs as they are (well, *should* be) driving logic chip inputs on the DAQ-PWM board.  I can't be sure, but I think that is a pretty safe bet.

Bob

242
Whoa, I just realized something.  I don't know exactly what the circuitry on the DAC-PWM board is, but...  if the "OUT Enable" and "Driver Enable" inputs are directly connected to the relay coils on the DAC-PWM board THAT WILL NOT WORK WITH THE PMDX-126!!!  And could possibly destroy the outputs on the PMDX-126.

The DAC-PWM board's relays need around 75mA of current at 5VDC to energize.  The PMDX-126 is only capable of outputting 16mA.  Trying to directly drive the relay coil could indeed make the voltage on the PMDX-126 output pin drop to 2.7V.  And 2.7V may still be high enough to turn on the associated LED on the DAC-PWM board even though the relay is not energized.

Even if the PMDX-126 *could* energize the relay, unless there is a protection diode across the relay coil on the DAC-PWM board, the indictuve kick-back from de-energizing the coil could destroy the PMDX-126's output driver.

Alas, I cannot find ANY specifications on the jtechphotonics.com website for what input current is required on the two enable inputs.  Not on the product web page nor in the instruction manual.  That is a question you need to ask J Tech Photonics - "can the enable inputs be driven by CMOS/TTL outputs?" and "do the enable inputs directly drive the relay coils?".

If the enable inputs directly control the coils of their relays, you will need something between the PMDX-126 output and the DAC-PWM enable inputs.  You can use the PMDX-104 (http://www.pmdx.com/PMDX-104) or the PMDX-105 (http://www.pmdx.com/PMDX-105, see section 2.6 in the user's manual) for this purpose.

Bob

243
Before I can try to figure out what is going on I need to know *exactly* how you have the PMDX-126 wired to the DAC-PWM board, including all of the connections to the DAC-PWM terminal strip with the Power, output relay enable, driver power enable, step and dir inputs.  I also need to know which output signal is controlled by your "flood" and "mist" buttons, so I know which input on the DAC-PWM  you are trying to control.  You can sketch a wiring diagram and scan/take a picture of it and post it here, rather than trying to describe what is connected to what.

Quote
For now im guessing that the 5V 10A supply im using drops voltage under load so the driver does not get enough supply...
If the output from the PMDX-126 is only going up to 2.7V when connected to the DAC-PWM, I don't think that is related to the DAC-PWM power supply drooping.  And that is easy enough to verify.  Put your volt meter on the DAC-PWM "Power In" and "GND" terminals and measure the voltage.  Does the supply actually droop?

Having the PMDX-126 output only go to 2.7V sounds more like something trying to overdive the PMDX-126 output (like a low impedance to ground or having the PMDX-126 output signal tied to an output signal from the DAC-PWM instead of an input.

244
I tried the resistor with all 3 sensors connected to pin 11.
OK, please try with only 1 sensor connected (and powered from your 24VDC power supply).  Then also try testing with 1 sensor connected and power the sensor from the PMDX-126's +12U supply on connector J12.  See if that makes the sensor's LED turn all the way (or most of the way) off when no metal is present at the sensor (and see if the PMDX-126's input LED turns all the way off).

Quote
The leds on my sensor are always on and just like the led for input pin 11 when metal is present they get brighter.  The leds on my sensor should be off and only turn on when metal is present.
Yes, *ideally* the sensor's LED should be all the way off when no metal is present.  However, the PMDX-126 input's pull-up resistor to +5V will always allow *some* current to flow though the sensor LED (from the sensor +24V to the PMDX-126's +5V).  If we can get the leakage current low enough the PMDX-126's input circuit will work even if the sensor's LED never turns all the way off.  And maybe we can even get the sensor's LED to turn off.  But yes, having the sensor LED remain "on but dimmer" makes visual diagnosis more difficult.  That is apparently the trade off needed due to the design of the sensor's output/LED and the PMDX-126's input circuit.

Quote
Since i'm using a Smooth Stepper I could connect my cycle start and hold buttons to inputs E and F on the secondary status input connector (J11) right?
Yes, as long as you have a second ribbon cable to go from the SS port 2 to the PMDX-126 port 2.  That will give you 5 additional inputs, the E, F, G and H inputs on PMDX-126 connector J11 and the K input on PMDX-126 connector J13.

Bob

245
Even though Mach3 is showing the correct input response, having the LED on the PMDX-126 for the "Pin11" input staying on all the time, even at varying brightness, is not good.  That means that the input circuit on the PMDX-126 is not fully switching off.  And while it works today the internal voltages are marginal and it may very well not work tomorrow.

Did you try the 470 ohm resistor with 1 sensor connected to the Pin11 input or with all 3 sensors connected?  If you ran the test with all 3 sensors connected please remove 2 of the sensors and run the test again with only 1 sensor connected the to Pin11 input (the other sensors can still be connected to the power supply and ground, just remove the black signal wires from the Pin11 terminal on the PMDX-126).

If having 1 sensor connected along with the 470 ohm resistor to +5V works (i.e. the Pin11 LED On the PMDX-126 turns off with no metal present and on with metal present), try again with the 1 sensor connected and without the 470 ohm resistor.

Do you have input signals connected to the Pin12 and Pin13 inputs on the PMDX-126?

Bob

246
I cannot quickly find a manual or catalog page that verified the wire color coding, so for now I'll presume it matches the standard color code.

I am guessing that the LED in the proximity sensor is causing enough leakage current into the PMDX-126's inputs that the PMDX-126 thinks is has PNP sensors connected and that they are active (trying to pull the input up to 24V).  If you have a volt meter or DMM handy, you can verify this by measuring the voltage between the "Pin11" screw terminal and the "GND" terminal.  If you see a voltage somewhere around 9 volts or higher (I don't remember the exact threshold) or higher with no metal present then that is the issue.  You can also look at the LED on the PMDX-126 next to the "Pin11" terminal.  If that is on (lit) all the time then leakage current is the issue.

Try connecting one of the sensors to the "Pin15" input terminal on the PMDX-126, and then change jumper JP5 to the "on" position.  Configure one of the Home inputs in Mach3 to be assigned to pin 15, active low.  With no metal present, the LED on the PMDX-126 at the "Pin15" terminal should be off and Mach3 should show the that home signal as in-active.  With metal present then the LED at the "Pin15" terminal should be on Mach3 should show that the home input is active.  Note that the LED in the sensor itself may remain lit all the time.  That is OK as long as the PMDX-126 input

If the sensor works on the Pin15 input, you can either connect all of the prox sensors to pin 15 instead of pin 11 and see if the input still works, or you can get a 470 ohm, 1/4 watt or 1/8 watt resistor and connect it from the '"pin11" terminal to the "+5V" terminal on J12.

You can try powering the prox sensors from the "+12U" terminal on J12 of the PMDX-126.  The PMDX-126 should be able to provide enough power to run the sensors (presuming you aren't powering anything else from the "+12U" or "+5V" on connectors J11 and J12).  I don't know if that will make the inputs work, but it might be worth an experiment.

Bob

247
To close out thread, the problem was indeed solved by uninstalling and re-installing the virtual COM port driver.

248
Oops - Steve answered as I was typing this.  Lets see if I can offer anything in addition to his answer.

The short answer is that if it works properly for M3 and M4 commands, then it is OK.  Just know that the spindle will run backwards when using the PMDX-107 test mode (which you should only need to do when setting up your machine).

If you want the PMDX-107 test mode and your M3 commands to both run the spindle in the same direction, then keep reading...

The PMDX-107 has several LEDs on it, including one for each of the solid-state relay outputs (in your case, one for "Run" and one for "Dir").  These are located just below the screw terminals for these two signals.  When you use the PMDX-107's test mode, the "Run" LED should light up and the "Dir" LED should remain off.

When you issue an "M3" command, does the "Dir" LED on the PMDX-107 light up or does it remain off?  How about an "M4" command?  I'm betting that the "M3" command causes the "Dir" LED to light up.

Since you are using a SmoothStepper (well, you were in your previous posts), you may need to tell Mach that the spindle "direction" signal in "active low".  See our app note AN002 on page 5 of the PDF document (http://www.pmdx.com/AppNotes).  If you are running Mach4 then I'm not sure how to configure the spindle.

**HOWEVER** making the M3 command match the PMDX-107's test mode will run your spindle backwards.  So you should also check your VFD manual to see if there is a setting that controls how its "Direction" input works, if there is such a setting.  Or reverse the wiring as Steve suggested.  If you cannot change how your VFD interprets its direction input, then leave the the current Mach/Smoothstepper settings alone and just remember that the PMDX-107's test mode will run your spindle backwards.

Bob

249
When the PMDX-126's EStop input is active (i.e. NOT grounded), the PMDX-126 will disable** all of its outputs, including signals to the PMDX-107 (which will tell the 107 to stop the spindle).  It will also drive the parallel port #1 pin 10 signal high.  As long as you have Mach3 configured to map its EStop input signal to port 1 pin 10 with a red "X" in the "Low Active" column and a green check mark in the "enable" column, then yes, the PMDX-126 will tell mach3 that the EStop switch was pressed.

One way to verify that the PMDX-126 is seeing your EStop switch is to look at the "EStop" LED.  This is located right next to the "E" in the "E-Stop" silkscreen on the PMDX-126.  The LED will turn on (and is red) when the EStop is active (i.e. switch pressed and the EStop input on the PMDX-126 not grounded).  The LED will turn off when the EStop switch is not active (i.e. switch not pressed and the EStop input on the PMDX-126 *is* grounded).

** "disable" means drive all of its outputs low (near zero volts), and de-energize both of the PMDX-126's relays.  Inputs to the PMDX-126 will still function normally.

Bob

250
It looks like the virtual COM port driver did not fully install.  I uninstalled and reinstalled the virtual COM port driver on your PC via the Teamwork remote access and left you a note on the screen of what to try next to see if it now works.

Let me know if this fixed your problems.

251
SmartBOB controllers and dedicated accessories / Re: Slave axis homing
« on: September 25, 2015, 11:47:13 PM »
Yeaaaaaa - I can't wait. Have you seen the plugin that decouples the slave axis, homes the A axis, and then recouples the slave axis. Interesting but I don't know if I trust it.
That is essentially how any gantry-squaring homing procedure works.  All motors on an axis are started at the same time and with the same motion profile (accel, max speed, etc.) so that the gantry doesn't become more skewed while searching for the home switches.  However, each motor stops when it hits its own home switch, regardless of whether the other motor is still moving.  Once each motor is positioned at an identical distance (possibly zero) from its own home switch, the motors are "re-coupled".  Usually this all happens in the plug-in or (more likely) in the motion device itself, and Mach4 is (again, "usually") never aware that the slaved motors have been effectively uncoupled and recoupled.

I think I remember seeing a thread somewhere (on the MachSupport forums?? I can't find it now) where someone had some Lua code that attempted to re-map the motors in and out of a slave axis configuration.

Bob

252
General Discussion / Re: X only moves to -.
« on: September 25, 2015, 04:22:01 PM »
PS: any thoughts on why I have to start a program before I can start my spindle?

My first thought is that you need to set a speed ("S" word in MDI line or click on "Spindle Speed" field and enter a non-zero value) in addition to clicking on the "Spindle CW F5" button.  It may be that when you run a file it contains an "S" command.  I bet that in your Config->Spindle Pulleys dialog you have zero as the minimum spindle speed.  Is that correct?  If the minimum speed is non-zero Mach3 will automatically "bump" the speed up to this minimum when you click on "Spindle CW F5" and you should see your spindle start up.

If that is not the problem, let us know and we'll see what else we can think of.

Bob

253
Thank you for the pictures Paul.  Its always nice (and often helpful) to see how someone's machine is set up.

3 things:

(1) Is your operating system a 32-bit or 64-bit version of Win7?  Even if you know off the top of your head, please go to the START menu and select "Control Panel".  If you see approx 8 groups of topics, then click on "System and Security", and then click on the sub-heading "System".  If instead of 8 groups you see lots and lots of icons, look for the icon named "System" and click on it.  This should show the Win7 version along with other useful info about your PC.  Take a screen shot and post it here.

(2) With the PMDX-411 plugged into your PC, go to the control panel again and select "Hardware and Sound", then under the "Devices and Printers" section click on "Device Manager".  When the device tree appears, expand the "Ports (COM & LPT)" section by clicking on the little "+" just to the left of that item.  Take a screen shot and post it here.

(3) And finally, I'd like you to run the test I described previously to have our plug-in create a log file so I can see what the plug-in sees when it tries to open the device.  Here are the instructions again:

Quote
I would like you to capture a log file for me so I can (hopefully) see what is going on.  See this post for the basic instructions: http://www.pmdx.com/PMDX-Forums/index.php?topic=97.0. You can still get to our configuration screens even if the plug-in can't find the device.  The following steps are important to do in exactly this order:

(1) Enable the debug log as described in the post mentioned above, then exit Mach4, wait a few seconds, then re-start Mach4.

(2) After you get the error message, go back to our plug-in configuration dialog and disable the log file ("restore defaults"), then exit Mach4

You now have a choice.  If you can find the log file (its location is given in the other post), you can attach it here to a post.  Or if you'd rather, you can create a Mach4 "package" and post that (or email it directly to me at bob at this domain)

Bob

254
First can you tell me what version of Windows, Mach4 and our plug-in you are using (see http://www.pmdx.com/PMDX-Forums/index.php?topic=100.0 items 1, 2 & 3)?

When you ran the installer for our plug-in, do you recall if you saw a second set of installer dialogs pop up towards the end of the installation process?  It should have said something about "virtual com port driver".

I would like you to capture a log file for me so I can (hopefully) see what is going on.  See this post for the basic instructions: http://www.pmdx.com/PMDX-Forums/index.php?topic=97.0. You can still get to our configuration screens even if the plug-in can't find the device.  The following steps are important to do in exactly this order:

(1) Enable the debug log as described in the other post, then exit Mach4, wait a few seconds, then re-start Mach4.

(2) After you get the error message, go back to our plug-in configuration dialog and disable the log file ("restore defaults"), then exit Mach4

You now have a choice.  If you can find the log file (its location is given in the other post), you can attach it here to a post.  Or if you'd rather, you can create a Mach4 "package" and post that (or email it directly to me at bob at this domain)

Bob

Pages: 1 ... 15 16 [17] 18 19 ... 25