Hi. I have a Sieg X3 with a Promica MX3 controller that has been working perfectly on a 32 bit version of Windows XP. I recently upgraded my home computer and as a result I had a surplus PC running the 32 bit version of Windows 7. The OS was a clean install and I also fitted a PCI parallel port at the same time. I have done all the normal prep including installing the latest version of Mach3, installing the old XML file from my previous PC, installing the drivers for the PCI parallel port and the Mach3 licence file however try as I might I cannot get Mach3 to communicate with the controller. I swapped back to the old PC to check the controller and it functions perfectly. I can jog the motors and run NC code so the controller is fine. I swapped back to the new PC and ran a driver test and it showed OK. I can jog the DRO's on the Mach screen but there is nothing happening on the stepper motors. When I enable the controller I can hear the steppers clunk so I know that the motors are powered up. I have checked the parallel port in Windows control panel and it says that the driver is installed and up to date.
Now for some strange things: When I first tried to run Mach3, the on screen reset button would not enable (see attachment).
It showed "emergency mode active" and "external Estop requested". I went into ports and pins and changed the output for the Estop from active high to active low. After this the reset button behaved normally. On my old PC the Estop pin was always active high! However on the new PC Mach3 will still not run the controller whether the pin is high or low.
Am I missing something? Do I need to reconfigure the whole Mach3 XML file? I understood that all you had to do when moving to a new PC was to put the old XML file into the Mach3 folder and then select that profile and everything would be sweet.
Any help or insights from experts would be most welcome because I am running out of ideas fast.
Regards,
Preso

Hi Preso,
I'm not familiar with your controller but your description suggests that it is governed by the parallel port.

It's not an ironclad test but running the Mach3 Driver Test program is simple and can often point you in the
right direction. Does it show a  'clean' or nearly so output. While I run my machine at a kernel speed of 25kHz
I sometimes test much higher, up to 100kHz just to get a feel for the PC's ability. Note that if you change kernel
speed you have to close then restart Mach to see the change, a mistake I've made.

Another useful test is to find the physical terminal on the controller board for the Estop and short it to 0V with a piece of
wire or a 100Ohm resistor if your concerned about letting the smoke out. It should signal Mach to Estop and if so
the controller can communicate with the PC. You could in theory test all inputs this way but becomes pretty tedious
often without learning much more.

If you have the original documentation for the controller find out if it needs an enable signal or possibly a charge
pump. A lot of non responsive BOB's are cured by getting the enable/charge pump settings correct.
Not sure why such a setting may have changed but subtle changes between one setup and another can be very
hard to spot.

One other possibility it the pullup/pulldown resistor settings. Not even sure that your controller has jumpers for
either but can be a source of much confusion when setting up. Given that you have tested the controller on the
old PC makes me think this is unlikely but sometimes changing something and thinking about the results will
inspire a 'lightbulb' moment.

Craig

Craig,
The driver test showed the same results as the old PC did but having said that I am not really familiar with what the graph is telling me. I do get a green bar in the status monitor and it reports excellent so I am thinking that the driver is OK. I will check the physical Estop which I have hard wired to the controller. When triggered on the old PC it would trigger the Estop in Mach3 but I haven't tried it on the new PC. I have to go away for a few days but I will try a few more of your suggestions. I tried going to ports and pins and reversing the motor step outputs from step low active to step high but again, no result. I am still rather perplexed as to why it is cranky with the new OS.
Preso

OK, I have given up. It appears that my PC is not communicating with the controller at all. I tried hitting the hard wired Estop but it had no effect on Mach3 at all. I have checked and reinstalled everything - twice. Once as Administrator and once as a user. No effect on behaviour at all. It seems as if Mach3 is very brittle. It doesn't seem to like Win7. I have gone back to my old PC. At least it worked. It just takes a long time to boot up.

Hi Preso,
I've been running Windows7 Embedded for several years now. It works better than
my XP machine ever did. Better still it ran pretty much perfectly from the time I
installed it.

Mach3 is not brittle!  The parallel port, also known as the pulse engine, can be fickle.
Depending on the exact hardware arrangement and/or competeing OS software it
may or may not work on some machines. The fundamental fact is that "A WINDOWS
PC IS NOT A GOOD CHOICE FOR A REALTIME CONTROLLER". How would you feel
about Boeing using a PC to fly their fly-by-wire Dreamliner! Try some searches for
realtime operating systems, they are out there, and even some Windows derived
systems which are 'deterministic' in the realtime engineers jargon. I couldn't get
any of the manufacturers to commit to paper a price for a one off licence for RTS
but was informed by my local distributor in Melbourne that I would pay $16000US
to get started!
The pulse engine of Mach3 is a VERY VERY clever bit of software coding. Art Fenerty who
wrote it made possible CNC using Windows PCs. To my knowledge no one has ever
matched it much less exceeded it. I'm glad Art used his talent to write it because if
he'd used his cunning to hack defence systems for instance the world would not be safe!

As to your specific situation its time to buckle down to the task of getting your pulse engine
to run on your platform and have it communicate to the PP. Confusing and sometimes
difficult but usually achieveable.

The other alternative is to use an external motion controller, there are plenty reasonably
priced examples. Without the 'trick pulse engine code' just about any PC can run Mach.

'When the going gets tuff the tuff get going...whimps throw in the towel'

Craig

Wow! I guess I have been told off. My problem is that I have tried everything that I know (I am a retired Industrial Technology teacher. Lots of experience with computers which started back in the days of the Tandy TRS-80 and lots of experience with CNC routers, Laser cutter/engravers and 3D modelling software and CAM software) however I am not a computer engineer. I asked for help because I was struggling. So far I have had a few suggestions but I was hoping that someone else might have a Promica Smart Controller running from Win7. I understood that I did have an external motion controller however it does not have a USB interface. Promica, the company (well, one guy really) that supplied my conversion kit, has folded  and there is now no support from that quarter. The Promica forum has been taken down too.
For what it's worth I did a clean install of Win7 32 bit and I have only installed the very basics on that machine. I have CamBam, Mach3, CorelDraw and the Chrome browser. I purchased a PCI parallel port but just to be sure I have ordered a second one just in case it is more compatible. I am still waiting for it to turn up. I also removed and refitted the graphics card and the memory. I have reinstalled drivers, rolled back drivers and still I am getting nada.  I am not normally one to throw in the towel but it was a case of using my mill or messing around with the computer that is meant to drive it. If someone can give me some specific advice I am more than willing to try it. It seemed though that the advice had dried up.

Regards,
Preso

Hi Preso,
sorry didn't mean to come over highhanded but giving up is the third and least desirable option.

The first test should be to check if the pulse engine is running, aka 'the driver test'

Set it running, as admin if you have to, and observe the results.
If the kernel speed is 25kHz, the default, the timer will issue an interrupt every 40us.
The driver test measures what variation in time delay the PC requires before servicing the interrupt.
A well configured/managed PC will have a variation of 3 or 4us and an occasional peak delay of 12 to
15us. The line of the graph give a visual representation of the data. The raw data is displayed in
text boxes below the graphics screen.

Once you've run an digested the info for the kernel at 25khz, close it and reconfigure Mach3 on the
ports and pins page to run at 45kHz say. You will need to close Mach and then restart Mach for the
change to be seen. Rerun the driver test, you may need to check the new kernel speed and observe
the results as before.

Would expect the absolute 'jitter' to be similar but to represent a larger percentage jitter but with any luck
the driver test should issue an 'excellent' rating. If this is the case there is reasonable assurance that it will
run at slower speeds with some margin. My old XP machine would run pretty well at 45khz poorly at
60kHz and crash at 100kHz. The new dual core Atom platform I use now while technically less powerful
than the XP it replaces runs sweet as a nut at 100kHz, go figure!

I run my machine at 25kHz and there is no advantage in running faster unless you need it.

My guess is your real problem is the communication between the pulse engine and the parallel port.
A lot of PCI cards don't work. A lot of them 'emulate' a PP with some creative conversion from serial
to parallel, they don't work. Have a read of the documentation that came with the card, sometimes the language used
will give you a hint that the manufacturer has used this technique. Post the details and maybe I can help.

Craig

Craig,
I have done the driver test and it reported excellent at all frequencies except 60khz. I ran my older PC at 25khz and the controller was fine at that frequency. I suspect that the PCI Parallel port is the problem. I purchased a cheap one via Ebay ($8.58) http://www.ebay.com.au/itm/162119544208?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
The documentation says that it supports Windows Vista/XP/2000/ME/98SE/LINUX above 2.4 (Not Win7) I am thinking that this one https://www.i-tech.com.au/sunix-par5018a-pci-2-port-parallel-ieee1284-card-par5018a-68356.html
might be better. Having said that I don't really want to be purchasing lots of PCI cards until I get one that works. If anyone can tell me a specific card or spec that works I might be able to have more success.
Regards,
Preso

Ok. I think I have made a breakthrough. It turns out that my PCI Parallel port driver was not installed. In my device manager, an entry showed up as "Multifunction Device" with a yellow exclamation mark. I assumed this was a printer lacking a driver but out of curiosity I right clicked and chose the update driver option and pointed to the Parallel Port driver disc. Lo and Behold a new LPT port showed up and it was listed as LPT3. (see attachment). Interestingly, an LPT1 was also listed in Device Manager and that was the port I was trying to use and install a driver for. I still don't know why it is there as I don't have a native Parallel Port on my mother board. I checked the port address for LPT3 and entered that in Mach3 under ports and pins. I was able to get the Y and Z steppers to move but the X refused to budge. The Y axis had way too much velocity and it would lose steps if I entered a G0.
Well, at least it was communicating. Later I tried to change the Port address to higher in the range but got nowhere. I tried to put it back to the previous address but stubbornly it made no difference. I closed an re-opened Mach3 just to see if that would make the change stick and the machine now worked like its old self. I am at a loss to explain why it took so many attempts with often inconsistent results. Maybe my dirt cheap Parallel Port was to blame. I still have not run any Gcode and I won't trust it to do so until I have done some dry runs. My apologies to Art Fenerty!  

Regards,
Preso

Hi Preso,
that's great news.
I bought a PCI card and I think I lucked out, it is based on a MOSCHIP device. It didn't
work straight up but after fooling around for a while and trying quite a few different
drivers I got it to work.
Can't really say that I understood exactly what was going on but it been working for me
eversince.

Craig