Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: WEMME on July 29, 2009, 03:59:54 AM
-
Hello,
I'm New to MACH3 I've had a look for this info so sorry I've missed the thread.
I have read it is not recommended to run anything other applications while the MACH3 is running a job on the computer as it will mess up the pulse train out of the Motors etc etc..... The reasons for this i understand and why this happens... My Question is.
IS THERE Hardware that SIGNIFICANTLY Buffers the stream so that This is no longer an issue ???
I want to be able to run other apps while MACH3 is Machining with out things going pear shape.
I Have been looking at the smooth stepper but is there any thing else out there that people recommend?
I AM Running Servos and Granet Controllers so want a fast Pulse rate.
Regards
Bart
-
Please don;t take this wrong as it comes up all the time.
What you are asking mach to do is akin to a BRAIN SURGEON talking on the cell phone AND watching a SoapOpera on TV while doing brain surgury on YOUR head.
IT can be done but why take the risks (;-)
(;-) TP
-
you can have a decent used computer for 100$, you better buy another computer to run your other stuff. it will still be cheaper then investing in some other hardware.
-
Your computer should be dedicated to CNC. Yes, you can have other stuff loaded on it,
but don't run other porgrams while machining.
RICH
-
Thank you all for your replys,
Mostly this machine will be CNC only however it is on a network and will be connecting back to a server.
to get the Cut files etc. I'm running 4000 count servos over 5mm lead ball screws so i will need i high pulse rate so will be looking at a hardware interface such as smooth stepper.
My main question really is Which hardware out there provides the best buffering etc
Regards
Bart
-
SO far there are only 2 that are advanced enough to be dependable and have support SS (step and direction)and dspMC (analog)
Just a thought, (;-) TP
-
Mach's parallel port drive is amazing. It is limited by the underlying PC hardware. No software generated pulse stream (on PC hardware) will be as accurate/smooth/jitter free as that from dedicated hardware. I've had decent luck with the parallel port but it can be a struggle on some PCs to get it working right and on some it will not work at all.
Using a PC for all the things it is good for (crunching numbers, nice display, etc) and a HW based pulse generator gets you the best of both worlds. It also completely eliminates the parallel port issue that many new users struggle with. I am a big fan of the SmoothStepper and reccomend them. Everyone I have sold them to have been really pleased.
-
If you are running w2K or XP, and you have dual processors (real, virtual or core), you can set the affinity and priority of each process. If you put MACH on one processor and any other heavy program on the other and set MACH priority to real-time, the OS will make every other running process wait on MACH, effectively making Mach the only program running (excepting memory use).
Other things to look at are using the drivertest to see how fast your computer can run the port. Note this doesn't mean the software can actually keep up with that speed.
The big thing it to get the task manager up and watch the CPU usage while Mach is running. If the CPU pegs, you're dead meat. A huge buffer is not useful if you are pumping garbage into the front of it.
Also note that not all processors are the same. I am using an old dual P3 processor server to run Mach. With no overclock, the processors run at only 850mhz. Mach is not multi threaded so one processor runs it without breaking a sweat whereas a 1.2ghz VIA chip would peg if you moved the mouse while Mach was runing g-code.
Disable your network while mach is runing and re-enable it to move files around. Use great caution with wireless networks. I find that for tiny g-code files, a thumb drives works beautifully as a transfer/backup mechanism.
-
Mach is not multi threaded
Oh yes it is! Among other things the toolpath display now runs in its own thread, any serial coms are also run in their own thread...
-
Jeff,
You must be using something special, then. When I run .026 of Mach, only one new process opens, even when the toolpath is active.
In any case, an application opening multiple processes is not the same thing as being multi threaded.
I can't comment on serial communication as I do not have any running with mach. Presumably you are referring to modbus?
-
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.