I am using the latest demo version. I am developing a hardware plugin that's controlled by mach3 brains over modbus.
The initial development stage requires me to have it simulated, before the PCBs are outsourced and parts planted (I need to show a working prototype before I'll get funding for it - only in software!).
I plan on using com0com and responding to modbus commands from a simple C program (running on the same machine as mach3), and the routines will be later ported to an embedded device. The idea - right now - is to show that the principle is viable, not to create hardware. However, mach3 doesn't seem to get along with virtual com ports, regardless of the OS. I have tried it on xp, 7 and 7/64 and it keeps failing.
Let's say I have 4 ports, COM1<->COM2, and COM3<->COM4. If I try to open, say COM1, mach3 will keep saying "Can't open comm[sic] port" in both the "test modbus" window and the "setup serial modbus control" window. COM1, however, will be now locked to mach.
However, if I click close the port, switch to COM2/3/4 and click open (or, after unchecking "modbus run", changing portnum to 2/3/4 in the "setup serial modbus control" window and checking "modbus run"), thus changing the port, mach3 will now LOCK both COM2 and not release COM1, and it will also say "can't open comm port". This happens regardless of how many ports I try it on.
This also happens if I try to use one or more FTDI emulator chips. Regardless of any other program (teraterm, hypertemrinal, bray's terminal) which can open the virtual pair or USB serial port (and even echo stuff back and forth), mach3 is unable to open them, and keeps locking the port exclusively, until it will be shut down.
How do I solve this? I need mach3 to spew modbus data on a virtual com, or at least on an emulated com port over USB.
The only solution I see for testing is hooking up two computers with a serial cable between their serial ports, running mach3 on one, and the emulated C slave on the other.
My assumption is mach3 fails to do this because it doesn't open the ports via kernel calls, but by directly addressing 0x3F8/0x2F8/... which (a) will not work on vista/7/8, even with administrative privileges and (b) is horribly bad programming, because my COM port can be something else, say "COM-MACHINE115" and mach will not only be unable to address it "MACHINE115 - must enter an integer" although the driver adds it with said name, and it's perfectly valid in other serial communication software - but it will also fail to read/write to its memory, because it might not exist on the I/O port address range at all (think non-standard x86 devices, which need a kernel driver).
I am assuming the reason this compromise was taken by the programmer was to allow the brains, which need to run in the 50-100Hz range to be triggered by the mach3 kernel driver and have serial port access. However, the first way I'd do it is simply exchange the brain serial data in a buffer, which will be processed by the mach3 app - thus allowing it to send data to com ports, as they appear in the kernel, and not only by the old I/O addresses). This assumption may or may not be good, since there are known examples of mach3 working with an arduino over modbus, which uses an FT232RL in the older versions, and needs a custom driver in the newer ones (which means mach3 CAN write to virtual com ports, but not com0com ports).
Guest
