Using dspMC and PPort together?

[halkintool]

That would be the general idea, i would mount one on the inside of my control head for lights, buttons and interface devices.

Those boards arent specific to the dspMC, you can use them with any DB25 cable.

[TOTALLYRC]

I would be careful using the 7711 with a pport.
While you could possibly use the 7711 board with a pport, a pport has a lot of the connections going to ground while the dspmc uses 24 of the 25 pins for I/O. I personally don't see what the problem is, just run a cable from the control head to the breakout board and be done with it.
While I am sure it would be nice to use the pport for I/O, I wouldn't use it for any time critical stuff. You have to remember that the motion is generated on the dspmc and not on the computer. If you use the pport for I/O, the signal has to go from the switch to the pport into the computer, then down the network cable and then it gets to the dspmc and finally it gets acted upon. It could be problematic if you were to use a time sensitive connection such as the estop, or feed hold.

The quick way would be to just run the db25 cable from the dspmc up to the control head and put the 7711 in the head cabinet. That is unless there is a distance limitation that I don't know about. It is not like the wire has to carry step and direction pulses to drive the axis at high speed, the worst it will have to handle is the MPG signals, which should be well within a 15' cables ability to handle.


Mike

[halkintool]

Running another DB25 cable an entire 30ft to the cabinet is overkill when the controls I want to install are less than 6" from the motherboard of the computer. Also, if you are running an MPG, you're running low voltage signals all the way along a table with all kinds of crazy voltage going on with a bunch of other cables vs. the MPG going right into the CPU and communicating with the motion control via the ethernet. The ethernet cable is proven to be reliable for motion and no matter what you do all motion is feed to the control via the computer in real time anyways, so i cant see how it would hurt the e-stop on the monitor has proven reliable and fast so anything coming through the PP should be just as good.  In my scenario, running a new DB25, opening up all the cable trays, rewrapping all the cables etc punching another hole in the cabinet etc is a lot more work than just making a custom DB25 cable to run to a few elements mounted to the face of my control head. Im also not adding any new external cables and its a lot cleaner as far as a resellable product.

[vitalsystem]

The I/O is all controlled by Mach3.  so if we allow access to PPort, it will just go to Mach3, not the DSPMC.  Only the I/O mapped to the DSPMC will go over ethernet.

the only problem I see right now is that the pport input scanning will be slow so you wont be able to use the inputs for a fast mpg.  regular on/off will be ok.


thanks
Rufi

[halkintool]

The I/O is all controlled by Mach3.  so if we allow access to PPort, it will just go to Mach3, not the DSPMC.  Only the I/O mapped to the DSPMC will go over ethernet.

the only problem I see right now is that the pport input scanning will be slow so you wont be able to use the inputs for a fast mpg.  regular on/off will be ok.


thanks
Rufi

No necessarily true.

If you input an MPG signal through the PP, it will go straight to the Mach3 software and translate into motion which is then communicated as a software command to the dsp. Same as if you had an e-stop input etc, the estop would communicate through the mach3 to the dspMC. As far as speed, i would assume it would work just as fast as it does on the screen which seems quick enough.

[TOTALLYRC]

I  think we can agree to disagree on whether or not to run a new cable as opposed to using the pport for the additional I/O.

Putting that aside, Windows is not a real time operating system, and neither is the ethernet port, which is why external motion controlers are better than the pport for motion control.
The data from the ethernet port has to be buffered and sent to the dspmc, and is not handled in real time.
When using a mpg, you are generating pulses at a high speed and you could and probably will exceed the speed at which the pulses can be accepted and handled by the pport and then sent to the dspmc.

I would say as long as you tell the operator that the mpg can't be trusted and he uses the dro's as gospel, you would be ok. What I mean by that is that if you are setting up and want to move say 1" and you crank the wheel ten times assuming .100" per rev and the machine only moves .920 or so, it will not engeder trust in the controls that you have sold the customer. While most of us would watch the screen and not count the MPG revs, when the 2 don't agree at all times it will make people think, if this doesn't work properly, what else doesn't work properly.

I think that things like coolant on/off, spindle control, and other non time sensitive stuff would be fine. E-stop, feed hold, limit switches and anything else time or safety critical should just be wired thru the 7711 to the dspmc.

Just my $.02.

Mike