Yes processes as show in task manager are not threads. Mod-bus, Ethernet, USB all are serial. Even the Vector drive plug-in I'm finishing does serial coms asynchronously (in its own thread) if you did not Mach would grind to a halt having to wait on serial coms to complete.

Multi threading is the thread split between two or more processors, yes? Mach's single process opens a half dozen threads, but that doesn't mean it is multi threaded, as in parallel processing of the same task by 2, 4, 8, or perhaps 4,000 processors simultaneously.

My multi threaded software, 3ds MAX and Adobe Premiere CS for example, open new processes when multi threaded operations start up (rendering, etc). The two processors can clearly be seen chugging away via the processor usage windows in task manager. So far, I have never seen Mach use more than one processor, even when it has one of them pegged.

Not everything can be multi threaded.  I don't see how multi threading serial communications has any benefit since it is serial in nature and multi threading is parallel in nature. True multi threading requires an operation that can be divided into discreet pieces that can execute in parallel using independent data . .  at least that is what we were told by the software engineers at Autodesk . . . .  I was a dealer for Autodesk many moons ago and flew to California for training more times than I care to remember. For muti threading a different compiler was used and therefor the processes are kept separate. Maybe that is different today, back then they were not using the MS compiler yet . . . . or  . . .  perhaps I am not remembering it correctly.

I recall that SS uses a driver (plug-in) and uses the USB buss, but what does Mach do with ethernet?

What is a 'vector Drive' that sounds interesting.

Remember computers have been multi tasking long before they had multiple processors. Separate threads do not need to run on separate processors, it just means they are running independently of one another, one does not have to finish before the other starts. In serial coms you tell it what to send and it goes off on its own and sends all those bits. You then get a callback if/when there is a response. The thread that asked for the communication to be sent does not stop and wait for a reply.

You can talk to a number of external devices over ethernet with Mach: G100, Galil, etc...

Also From what i read its more the interrupt latency than cpu power that is the real issue here.
Thats why i've been looking for a Micro controller board to off load the timing issues.

Remember computers have been multi tasking long before they had multiple processors.

In the realm of PCs, I agree.  In any event, methinks this is one of those symantics things; multi-tasking vs multi-threading.



I've been wanting to talk to servo drives from MACH and it sounds like you might be a good go-to person for serial communications questions related to Mach . . . .  so:

I know of three possibilities (four if you count writing a plug-in, which is beyond my capabilities) to get mach talking to the serial port.

1) is one of the 'semi-documented' VB script commands, but there is only mention of output on that one.

2) again VB script, but this time a generic routine thatone would have to flech out with all of the parameters for serial port control.

3) a recently posted technique using what appeared to be a Windows TSR that is called (I think) also thru VB script. Nobody really took the bait on that one and it faded quickly.

So, Mr. Birt, how difficult would it be to get bi-directional RS232 comm going that is callable from within Mach?

methinks this is one of those semantics things; multi-tasking vs multi-threading.

Sort of, multi-tasking works by dividing the processor time between multiple process/threads running on the machine. A process (task) can be made up of multiple threads. Even though all of these threads are running on a single processor the advantage is that they are running independently of one another. If one thread is waiting on disk access the thread redrawing the screen can still do its thing without waiting for the disk access to complete.

As to the question about talking to serial servo drive through Mach's VB script. You won't be able to do that, it is just too slow. If you want to try and talk to servo drives over a serial link then it needs to be done via a plug-in. When I get the vector drive plug-in done I'll post it as a reference.

I don't need speed, I don't think, because I would not be trying to do any sort of motion control. What I would want to do is simply  change the drives parameters. Change the following error setting and or turn faulting on and off. Maybe change the PID for different purposes, perhaps reset the drive, stuff like that.

All would be done while the machine was idle and not while running g-code.

Since Windows is a mutil-tasking OS< I could bounce out of Mach and talk to a drive with another APP, but that's not really the setup I'm looking for. I want to be able to do it unattended . . so I think that will require firing up either RS232 or USB from within MACH, utilizing wither VB script or maybe a brain (haven't crossed that bridge yet).

So I'm just looking for the mechanism to do it. Not a big priority at the moment, since the Rutex drive I am using doesn't comm over RS232. It's just an idea that I've been noodling over.

OK, that is basically what I am doing with the vector drive plug-in, I set the mode, direction and RPM. The rest of the interaction is done via handshaking with hardware lines (enable, etc.) You might be able to use it as a framework for what you are wanting to do.