[jeffery926]

Hello,

I'm a new Tormach user and have finally got my 1100 up and running and successfully cutting. My dilemma is the transfer of files from my Solidworks machine to my Tormach PC controller. My current method consists of a USB memory stick that I will move from CAD/CAM station to the Tormach to dump the nc file to the desktop. I do not have the Tormach controller on the network (as advised by Tormach) and therefore would like to find a way to wirelessly transfer files between computers. Does anyone know if an SD card with wifi would work? If I had the SD card plugged into an SD card reader into the USB, could I transfer the files successfully over wifi?

Curious to hear your thoughts,

Cheers!:cheers:

Try a Toshiba USB Bluetooth adapter. That is how I transfer files from and to several different PC's in my shop including my Mach3 controlled CNC routers.

Toshiba Bluetooth&#153 V2.1+EDR USB Nano Adapter from Toshiba

[BAMCNC.COM]

Smoothstepper moved to Ethernet for a reason.... Right...?

[kevinro]

The way it was explained to me was that the electrical timing signals sent from mach3 to the mill are prone to corruption by other system functions. Such as RAM, HD read/write, CPU usage, USB usage, and bandwidth on the serial port. So the fewer other programs/things running, the fewer corruptions.

Once, a long time ago, someone who knew very little about how all this control stuff actually works declared a whole laundry list of reasons why things fail. They explained it with such force that it has now become religious belief. It still amazes me how pervasive information like this is, even though nearly none of it is accurate!

I normally try to stay out of these arguments, since they are so steeped in dogma and incorrect information that I could spend the next year doing nothing but trying to change peoples minds.

I helped write the Windows operating system. I have a degree in Computer Science, was a senior design engineer at Microsoft, and also do a lot of embedded control work including lots of robotics and motion control work.

Any modern computer running your mill is incredibly fast and completely underwhelmed by the task that Mach3 is performing. Servicing interrupts, even on a network card, happen so fast and on multiple processors that is very doubtful you would ever see an issue. It is possible, of course, that some poorly written driver could hold a spin lock in the kernel and prevent another driver from running, but most decent generic hardware runs the default drivers from Microsoft which have been pretty well vetted.

Using a bit banged parallel port is a poor choice of control methods on modern computer. A parallel port is so incredibly slow compared to everything else on the computer that it is likely to be the source of any timing issues. The computer is going to generate many wait states while that pokey old bit of hardware does it's thing.

Windows and Linux are more than capable of doing real time control. Somehow a myth was started long ago that it can't. There is overhead in both systems, but it is so tiny in comparison to what the computer can do it really is not an issue. If you think it is, in Windows, you can actually set the priority of a task to REALTIME_PRIORITY_CLASS / THREAD_PRIORITY_TIME_CRITICAL in which case the CPU belongs to the real time software. No interrupts or task switching will happen in that thread. Nobody really does this, however, since it is not necessary to dedicate a 2.2GHZ processor to sit and wait for an eternity for the real world to catch up.

The computer hardware that windows is running on may not be able to deal with real time control, and that is more of an issue than the operating system. The PC's architecture is tuned for a different problem set. The chipsets are tuned to keep the CPU's running free and clear on high speed busses. The parallel port is like an old cobblestone street that the computer has to slow down for. With multiple bus operations occurring at once, the bus controller puts the parallel port down to the lowest priority.

I think the bottom line is: 1) Windows and Linux are really not the problem people believe they are 2) The PC hardware generally work pretty well 3) The parallel port is an outdated and decaying design.

One of the few areas that can cause either OS to appear to 'lockup' are when errors are detected and corrected. For example, if you pull out a USB key while it is being written to can cause the system to retry the device a few times during a system call. A hard drive error, especially a paging error, can cause a process to miss it's allocated time slice. There are lots of device errors that can create an issue. If you are having lots of them, I recommend checking the event log on the computer. If you don't know what that is, find a nerd!

[SCzEngrgGroup]

The speed of the PP hardware itself is a non-issue. The issue is the latency, and timing jitter in that latenct, in interrupt servicing of the Mach3 "kernel", which, effectively, runs *under* Windows. The Mach3 kernel is servicing interrupts at the kernel frequency (typically 25kHz, or more). The latency in servicing these interrupts is what determines the accuracy of the timing of step pulses to the motor drivers. With steppers especially, jitter of a few uSec is enough to induce lost steps and stalling. Further aggravating this is the fact that Mach3 is not multi-threaded, and even GUI updates run in the same thread as the trajectory planner and other critical activities related to motion control. This is one of the major changes in v4 - it IS multi-threaded, so GUI updates, like rotating the toolpath display, run in a low-priority thread so they cannot affect motion control. Basically, *anything* in the system that can in any way affect latency in servicing Mach3 interrupts has the potential to cause problems, especially in stepper-based systems. This is also why use of a motion controller will enable many machines to run much faster, as this timing jitter is eliminated almost entirely by generating the step pulses directly in hardware. All anyone has to do to prove this is to look at the step pulses with an oscilloscope, even while doing a simple constant velocity high-speed move. Using the PP, the timing will be all over the map, even on a system that appears to be running well. Running other CPU-intensive applications, or manipulating the toolpath display will make the jitter even worse. Move to a hardware motion controller, and you'll see rock-solid timing under all conditions. I saw one machine that would run only 75 IPM, due to severe jitter on the step pulses. I put in a motion controller (KFlop), and, with no other changes, could run over 300 IPM.

Regards,
Ray L.

[kevinro]

Running other CPU-intensive applications, or manipulating the toolpath display will make the jitter even worse.

(Edited: I just reread what you wrote in the words Mach3 "kernel", meaning that Mach3 is doing something that is not actually interrupt driven? My comments are kernel interrupts as in Windows kernel interrupts. Might be we are talking at two different levels here).

Close. Latency of interrupts has nothing to do with CPU intensity of an application. The interrupt is going to happen, the CPU intensive application is going to get interrupted (hence the reason for interrupts!). What will actually get you into trouble is I/O intensive operations. Anything that is taxing the I/O controller will cause a problem. Now a CPU intense / memory hog of a program on a machine without enough memory will cause above average disk I/O from paging or other disk I/O, which on all of these operating systems is going to take priority over the parallel port (which is dead ass last in priority). So you are fighting for interrupt priorities and bus time. Having said that, on a modern computer with multiple cores, this isn't really as big of an issue as it sounds for doing things like running a network card, or another small application.

Another culprit is likely the architecture of Mach3. On message systems using message based interprocess communications, Mach3 can end up having to wait for messages to get dispatched to other windows on the system. Even if run at high priority, there are going to be cases where it has to process messages that it isn't interested in. Such as the case where the display is updating, or a system wide broadcast message gets sent. In this case, it isn't so much that the hardware is having interrupt problems, it is that the Mach3 program isn't keeping up.

If you wanted to be safe, you can start Task Manager (right click on the task bar), right click on Mach3, and do a Set Priority Above Normal or High, which will give Mach3 the CPU whenever it needs to run. I don't recommend setting it to Realtime as it isn't written to take that priority and you could deadlock your computer.

[samco]

In my opinion - linuxcnc does pretty well at stable software stepgen. You run a latency test to actually see jitter while loading the system. (surfing, copying files, network loading, playing videos and so on.)

Though - there is very inexpensive interface solutions for linux. There is the 5i25 $89 ( from mesa that right out of the box acts like 2 printer ports on steroids. (high speed step, pwm, encoder counting and i/o) ) This is also very expandable - able to run analog servos and such with daughter boards.

This does the heavy lifting so the computer can run a slower thread (servo - 1 to 10khz or so) Vs aprox 20 to 50us...

I have used mesa hardware and it is an industrial quality solution.

sam

[BAMCNC.COM]

If you wanted to be safe, you can start Task Manager (right click on the task bar), right click on Mach3, and do a Set Priority Above Normal or High, which will give Mach3 the CPU whenever it needs to run. I don't recommend setting it to Realtime as it isn't written to take that priority and you could deadlock your computer.

I said this a while back, glad to see some backup here...

[Hirudin]

Seems that everyone agrees: using something like a SmoothStepper basically eliminates the non-realtime issues with Mach3 or LinuxCNC. Whether those issues are critical, merely a nuisance, or completely imagined.

To focus on the title of the thread a little bit here: is there a way to hook a SmoothStepper et al. to a Tormach machine? Obviously, you could "unlock" the comupter and just use normal Mach3, but does Tormach provide a way to use a motion controller within the Tormach optimized Mach3?

To put it another way: is a SmoothStepper, a wireless network card, and unlocking Mach3 the answer to the OP's dilemma?

How about an SD to SATA adapter? Hook an EyeFi up to it - no USB, Windows isn't handling the networking, and rockclmbr gets his/her wireless file transferring.

http://www.amazon.com/Elecity-SD-TO-.../dp/B003NVJA86

[samco]

Not quite with linuxcnc.. Linuxcnc is the motion controller. (none of the current interface solutions for linuxcnc are 'motion controllers' in the smooth stepper, kflop sense.) Linuxcnc still requires a realtime patched kernel - though with the high speed stuff moved to the interface card (pwm, stepgen, encoder counting and such) linuxcnc can run just the 'servo thread'. usually around 1 to 10khz.

sam

Seems that everyone agrees: using something like a SmoothStepper basically eliminates the non-realtime issues with Mach3 or LinuxCNC. Whether those issues are critical, merely a nuisance, or completely imagined.

[Wirecutter]

Seems that everyone agrees: using something like a SmoothStepper basically eliminates the non-realtime issues with Mach3 or LinuxCNC. Whether those issues are critical, merely a nuisance, or completely imagined.

To focus on the title of the thread a little bit here: is there a way to hook a SmoothStepper et al. to a Tormach machine? Obviously, you could "unlock" the computer and just use normal Mach3, but does Tormach provide a way to use a motion controller within the Tormach optimized Mach3?

I would also like to hear more about this, and I'll start a new thread as such.

-Mark

[concombrefrais]

I have used dropbox for a couple of years and never had a problem. I know it is against Tormach guideline but I figured I would give it a try, I am glad I did. My computer is a 10 years old dell and it has nothing installed except mach 3 and dropbox. May be someday I will trash a part because of my foolish use of dropbox and the fact that dropbox interrupts the kernel latency of the X120bis super cooled parallel infinite RAM of the vortex inside my mouse, god knows. I don't care, I am wild.

[Hirudin]

Regarding the Eye-Fi card that I mentioned earlier: I've now done a tiny bit of research on Wi-Fi SD cards. It looks like the Eye-Fi cards would be a bad choice. As far as I can tell they require special software and restrict which file types you're "allowed" to transfer. One review I skimmed through also suggested that Eye-Fi might be one-way only. If that's the case they would be totally useless.

There are other choices for wireless SD cards though; I have to imagine one of them would be better suited for this application.
Here's a comparison of three of them...
Re: Eye fi vs Transcend vs Toshiba Flash Air in m4/3?: Micro Four Thirds Talk Forum: Digital Photography Review
Another brand to look into is "EZ-Share".