OK, so made big progress last night on the drive communications. LUA 5.2 included with mach comes with a package/module/library called luars232.lib. This gives basic serial port access but the documentation is essentially non-existent. I am not a programmer by trade, so I tend to rely very heavily on provided documentation.
I used the only piece of example code out there for this library to add a serial port open command to the screen load script in Mach. When Mach first opens, it connects to the embedded serial port on the PC and configures the baud, parity, and data format. I get a little message at the bottom of the screen that says "Serial Port Open". It also handles errors like if I forgot to close Ultraware before running Mach and the serial port is in use. I also added the close serial port function to the screen unload script. This kills the port when Mach closes. I bet Windows does this anyways but I figured it was good practice.
I then created a new blank tab on screen that gave me room to add some test buttons. The first one simply wrote "Hello World" on the serial port and sure enough, the first try I received a "Hello World" on my monitoring laptop. The second button sent a line of text that was a drive command, however the drive would not respond until I ended the string with a "\r" which LUA interprets as a carriage return. This correctly transmitted and I saw a drive response. The next two buttons were Serial Port Open and Serial Port Close, and attempted to do exactly what you'd expect. The close button worked perfectly, and the previously mentioned buttons would no longer transmit once it was closed. The open button used the same code from the screen load script, however it never successfully reopened the port. I wasn't too concerned so I moved on. I might come back to this.
The next button flushed the serial port by reading 1 character at a time until no data remained or the maximum windows serial buffer size (4096 bytes) was reached. I also had it announce how many characters were flushed. I was very happy to see that it always flushed the number of characters that the drive responded with, so I was pretty sure Windows was buffering the right data. The next button read 14 characters and concatenated them into a string which was then printed to the screen. And what do you know, I was able to print the drive's response to the screen! This of course only worked because I knew the response would be 14 characters. I added a few more drive command transmit buttons to send and receive strings of differing lengths.
The final button closely resembles the function which will actually handle the communications from the drive. When clicked, it flushes the serial buffer character by character until a ":" is found. It then reads the next two characters to get the drive address and the following 3 to get the parameter code. Using the parameter code, it does a table lookup of supported parameters and finds the expected data length. Next it reads the correct length and concatenates all of the data together to be printed to the screen. This function correctly handles variable length responses from the drive so long as I add them to the table of parameters. Any junk data is thrown out.
When I have time I will next make a button which verifies my checksum function I have already written works, and a button which will convert the data received from the drive and store the decimal form of the data in a register for use anywhere in Mach.
The final code will be a little more complicated since I need to send -> delay for response -> read. The delay must not block the rest of the code from running so a LUA coroutine will be used. I tried playing around with these and found them powerful but confusing.
All in all, I have proven that each piece of the puzzle works and I have confidence I can communicate with these drives automatically through Mach 4!
