Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: jydencnc on March 01, 2018, 08:32:02 AM
-
Hey, I have this project where i need 3 Axis with home switches, and a THC (Plasma Torch Height Controller) for my Z axis, with a plasmacutter.
That means i need 6 digital inputs. And My geckoboard540 only have 4 digital inputs.
too solve that problem i want to use a second board which is the standart mach3 interfaceboard.
My computer is a laptop hp probook 6570b (windows 7, 32bit), without db25 parallelport. So i got two uc100 motion controllers.
But, when i start mach3 it forces me to choose between those two uc100 controller, but i can actually see, both of them the plugincontrol, in/out monitor, they react when I affect the inputs.
Other then that, i only have one ECP-printerport (LPT1), with the following adresses: 0378 - 037F and 0778 -077A.
The first address works fine with (port1= 0x378). But the second port2= 0x778 doesnt work.
Then i have tried to make second ECP-printerport (LPT3), manualy, but it has problems finding a free address.
But yet it found a free, weird address which is (LPT3 = 03BC - 03BE. But it does not work either.
Are there Anyone who can help me plz :)
Sorry for my bad english.
-
Get a UC400ETH.
You can't use more than one motion controller, and you can't use both a motion controller and parallel port together.
SO you need a motion controller with multiple ports, like a UC400ETH.
-
Get a UC400ETH.
You can't use more than one motion controller, and you can't use both a motion controller and parallel port together.
SO you need a motion controller with multiple ports, like a UC400ETH.
Okay, thank you very much! :)
-
Hi,
ger21's suggestion is the most straight forward. I think the UC300 from the same company has five 'ports worth' of IO....even more than the UC400.
I know Mach4 can accommodate more than one board, it can still only have one motion controller. For instance you could have an ESS as the primary
motion controller but have a PoKeys 57E and its plugin installed and use all the extra IO on the board. You couldn't hook motors up to it and expect
them to move synchronously with the ones hooked up to the ESS. In fact I'm not sure that you can run out-of-band motors from any board which is not
your primary motion controller but you can certainly use all its IO.
I was of the opinion that a similar thing could be done with Mach3, that is have one board as a motion controller and a second board as extra IO.
I suspect the plugin for the UC100 which is designed to be a primary motion controller is unsuitable for use as IO alone and would not therefore work.
Craig
-
Guess what happens if you using 2 devices connected to one computer with the same software.
The main problem is Windows and so Mach is not realtime, so both controllers will have a communication latency and have to use buffered communication to work quasy realtime. Realtime at least to themselves and giving the illusion of realtime working to the user.
So, you have 2 controllers then guess what happens when you configuring a home input to one device and configuring the axes motion to the other device.
When device 1. gets a home input switch trigger when the axis reaches the home switch then device 1. can't interact directly on the signal, because it is not the one in charge for the axes movements, but device 2. is.
Now what device 1. can do is it informs the software on the PC. Now this is one delay, because to send the data out and to receive it takes time.
Now what the software can do is it can send a signal to the motion controller telling it that the home movement has to stop, because the home switch was reached. Now this communication is a second delay.
These 2 delays add together, however even one delay could cause a crash of the axis, because if the speed of the homing is high enough and the communications delay is large enough then the axis will already crash into the home switch or to the mechanical endlimit before the controller device 2. would even be notified about the home switch reached event.
This was just an example, it could be told with other signals too, like limit switches, probes etc.
Also what if one device disconnects and has to tell the computer to stop the motion and the computer has to tell the other controller to stop motion, because there is an issue with the other controller.
What if the other controller implements disconnects incorrectly and the computer side software does not even know about the disconnetion while important signals are configured on controller 2.
So, using 2 different controllers to handle signals is very unsafe in my opinion. I think even the concept of handling signals like that is dangerous.
The only safe way I see is to handle all signals on the same controller and then that controller should have as many I/Os as required for the application and that one controller should handle time critical signals directly and only when the event is handled it can notify the PC side software letting it know that this and that happened, so there is no delay at all in handling these type of signals...
-
Hi,
for time critical systems that may be true. However it is perfectly acceptable and is in fact done, certainly in Mach4 anyway, that a board other than the motion
control board be connected to buttons, switches, pots and MPGs which make up control panels.
In Mach4, and if I'm not mistaken Mach3, home signals are handled by the motion controller and that obviates any delay. If a second board were to monitor a home switch
it would have to communicate that event to the motion control board and would fail due to the communication delay. Additionally the motion control board is designed and
expecting a home signal 'on board', how would you go about signaling the homing routine about an event monitored elsewhere?
I don't know about limit switches, I suspect they are, at least the initial response, handled by the motion controller also. Probing inputs are certainly handled at board level
and could not be spread across two boards.
Craig
-
Yes, you basicly told the same what I said, but the UC100 is a motion controller board and the OP is talking about connecting 2 of them is what I was answering to.
For non time critical signals it might be not a problem using a separate board to handle those signals other than the communication delay, if that is not a problem for a non time critical signal then there is no problem,
but the UC100 is not a board to handle auxiliary signals, it is a motion controller with a motion control plugin, so it works as a motion controller.
-
Hi,
it is a motion controller with a motion control plugin, so it works as a motion controller
Which was exactly my surmise.
Craig
-
for your extra io get the pokeys board
-
Thank you guys, I have ordered a uc400eth and hope that will help me.
I only need the extra inputs for my THC(Plasma Torch Height Controller).
"That is not a problem for a non time critical signal, then there is no problem"
-
Hi,
THC is time critical and it is handled in the controller rather than Mach but I think you'll find the UC400ETH does it well.
Craig
-
THC is not only time critical, but that whole control is handled directly by the motion controller because Mach and Windows is not realtime and THC control has to work instant.
The UC400ETH implements THC control and ethernet is much better than USB for electrically noisy applications like plasma control, because ethernet is isolated while USB is ground referenced.
So, using a UC400ETH is a good solution.
-
Hi Dubble,
I know that you have recently released Mach4 plugins for the UC100 but I believe also the UC300 and UC400.
Does the Mach4 plugin provide THC support?
Craig
-
https://www.intervalzero.com/real-time-operating-system/
-
Hi Dude1,
have you seen the price on that sucker! Last quote I had from MS in Austrailia $16,000US without licences,
thats just the tools!
Craig
-
I know
-
Can anyone contradict me please ?
I do not see how Mach 3 would be able to "talk" to more than two ports "at the time". Therefore, the nice UC300-5LPT appears useful for a User who has in mind to use, say a mill that needs two ports worth or In/Out and a lathe with another set of two ports. But how about using a third port ?
If I'm mistaken, please correct me, I'd be more than happy to be able to use more than two ports "at the time".
PS: the "at the time" quote is the necessary care needed when we are talking about systems which are not meant to operate in real time.
-
When using a motion controller, Mach3 can access as many ports and pins as the controller has available.
Only parallel ports are limited to two at a time.
So you can indeed access all 5 "ports" worth of I/O pins on a UC300 from Mach3.
Be aware that with a UC300, not all of the ports are the same. Two are mapped as "Standard" parallel ports, while the other three use pins 2-9 as inputs only.
-
Gerry, thank you for contradicting me.
What I miss, is the pathway to tell Mach 3 to use the resources provided by the three additional ports not offered in the main config menu.
It is clear that two LPT like ports can be directly configured, less so (for me) for any other one.
Is it sufficient to define a sole port number that differs from the two used in the main config menu ? This is not obvious from the documentation that is available to me.
If for example I assign ports 1 and 2 in the main config, I could be using implicitly ports 3, 4 and 5 (in the pins menu) to get access to all the other resources ?
cheers, Philippe
-
The LPT port addresses are not used at all with a motion controller.
On the ports and pins pages, you just enter the port number defined by the manufacturer of the motion controller. In the case of the UC300, they would be ports 1 through 5.
-
Thank you. That seems to be the misleading point. In the main config page, there are two possible entries for LPT ports; say 1 and 2.
In the ports and pins page, I'm using a port number, say 1, to talk to one BoB connected to the UC300. The missing bit: this "1" is NOT connected to the connector numbered "1" on the UC 300 but on the second. I agree that there is no "rule" that forces anyone to number "ports" and " associated connectors" in a coherent manner, but one would think ...
Documentation is not coherent, in my modest opinion.
cheers, Philippe
-
In the ports and pins page, I'm using a port number, say 1, to talk to one BoB connected to the UC300. The missing bit: this "1" is NOT connected to the connector numbered "1" on the UC 300 but on the second.
The port numbers on the UC300 are the numbers you enter in Mach3. If you enter a port number of 1 in Mach3, it will indeed be for port 1 on the UC300.