Is the manual for this router available online somewhere? Something that explains the serial protocol it uses? Can you post a link? I’m wondering if perhaps it expects some sort of termination after each command, or something else.
So I think I figured out the immediate problem: Padding hex values to be 2 characters instead of 1
It turns out that for channels 0-15, .toHex was producing single-character hex values and the machine wants it to be 2. So for channel 2, it should be “02” - if you send it “2”, it doesn’t recognize the command.
There are manuals online - very simple actually. There are a couple variations because the commands are a little different depending on the number of channels the unit supports.
16x16: http://www.z-sys.com/lit/16-000.pdf
32x32: http://www.z-sys.com/lit/32-000.pdf
64x64: http://www.z-sys.com/lit/64-000.pdf
However, because of the flood of responses that I get back from the machine if I send it a flurry of commands, I think I probably need to build some kind of queue that sends one, then waits for a response before sending the next, so that I can keep them straight.
.ToHex(2)
Gives “02” instead of “2”
Thanks. It seems that packets sent to the router start with a “begin communication” end with a “end communication” byte. Is it reasonable to assume that data sent back from the router also uses these characters? If so, then you can listen for the “end communication” character to determine when it’s safe to send the next packet.
That would seem reasonable, wouldn’t it? Unfortunately it doesn’t, it just send the result. So I don’t see any other way to keep things straight than setting up some kind of buffer that stores the outgoing messages, and another for incoming, then sorts things out.
Well, if it doesn’t terminate the return data with a specific character, is the number of bytes in each response constant? I.e. does it always return the same number of bytes? If so, you can use the SerialConnection.BytesAvailable property to wait for the right number of bytes before reading them from the buffer.
I think that would work, yes. In my tests there was also a space between each response, so that could be used as a delimiter to separate a response where I get several results in one go.
I have this all working very well on my mac from the debugger. I decided to compile it for the mac that runs our audio capture workstation, only to remember that I upgraded Xojo last fall and can’t compile for High Sierra anymore. Which really sucks.
So I decided to compile it for Windows and run the router on a windows 10 machine that happens to be in the rack nearby. It’s not ideal since it means having to switch computers to set up routing, but it will work until I can figure out a better setup. Anyway, I took the Dtech USB serial adapter and the cable I made, which works perfectly on the mac, over to the windows machine. Plugged it in, Windows recognizes the adapter and installs drivers. But I also downloaded the latest driver from FTDI just in case and when I tried to install it it told me the one already installed is newer.
My app recognizes the port (at COM4 - confirmed it’s the correct port by watching the serial ports in Device Manager when plugging/unplugging the adapter), but when I try to send something from Windows, I don’t even get Tx lights on the USB serial adapter. I downloaded SerialTool for windows, and same thing - I can’t send from that either, even though it sees the serial port is there.
Everything is identical (hardware-wise) to what was connected to the mac - even the router is the one I had on my desk - but it it won’t work on Windows. Any ideas? This is clearly not an issue with my app since SerialTool has the same problem. But if the driver is installed and appears to be working for the USB serial adapter, what else can I try?
You might want to try to replace the driver on your PC with the latest one you downloaded.
Are you using any handshaking? If so, try turning it off and see what happens.
1 Like
This did it - at least as far as getting the connection right. the driver I downloaded was the version you’d use if right clicking on the device and selecting “Update Driver”, which of course doesn’t work if you remove the driver, unplug the device and plug it back in - because Windows automatically installs its own. It took some doing, but they have a Setup application version of the driver install (not obvious because the link to it was in the comments section on the driver table). That allowed me to uninstall the Windows driver and install the FTDI driver. At that point SerialTool started to work.
My app, however, is not working so I’m going to have to figure that out now. It’s just fine on the Mac side.
that is a good point. Perhaps one of the handshake lines (RTS, DTR) is in the wrong state when the port connects. Perhaps the adapter is behaving differently on Windows than it does on macOS. I would definitely try playing around with that to see if it makes a difference.
I don’t know what flexibility SerialTool offers when it comes comes to manipulating handshake lines, but you could try CoolTerm (#ShamelessPlug 
), which lets you set the initial states of these lines when the port opens and also lets you toggle them manually while you’re connected. And, it’s written in Xojo 
.
1 Like
Thanks. I’m going to be away for a few days so I’ll try this next week. In the mean time I’m back to getting this working on Raspberry Pi. It was shockingly easy to get the Pi system set up and running, and my app just fired right up. I need to make changes to make it work on the touchscreen (wider UI to take advantage of as much of the small screen as possible), so I’ll be testing the serial functionality there as well. I had planned to hold off on making it work on pi for now, but just decided to go for it this morning.
So this turned out to be operator error. I made a couple quick last minute additions before leaving the office, thinking I’d finish it off in the morning. Didn’t get back to the project for a couple days and forgot I did that. It appeared to break all my serial comms, but in fact it was just the display of the responses that was broken. That’s all fixed and it’s back up and running. In the mean time I decided to go ahead and build this for Raspberry Pi, built a nice racmount enclosure, and now I’m focusing on tweaking the UI to fit the flat panel screen. Hoping to get this installed and running this week, so I can move on to other projects. I’ll update here (or probably in a new post) with photos of the whole thing running once it’s all up.
1 Like