For some time now I’ve been working on a motion picture film scanner. The motors, lights and sensors are controlled by a Teknic Clearcore microcontroller. Last year I hired a developer to write the firmware for this. It worked reasonably well in initial testing, but we had to shelve the project for most of this year for unrelated reasons. I got back into it about a month ago, found some bugs, and when I contacted the developer I found out he’s seriously ill and unable to work on it anymore. I had someone else, already familiar with the ClearCore and the motors we’re using (also made by Teknic), take a look at the code. He can get us limping along, but his suggestion (and I tend to agree) is to rewrite it because there are some fundamental issues with the current setup.
Some of what had been done by the first developer is a bit buggy, and in some cases he determined it was best to do some multi-step functions on the ClearCore then report results back to me. Unfortunately, the code is a bit of a mess, and the setup we used involved two TCP channels: a server on my desktop app to receive unsolicited alarms and errors from the ClearCore and a server on the ClearCore to receive commands from my application. This has proved to be …clunky at best.
The new guy suggests a completely different way of approaching this: A single TCP connection to the ClearCore, using modbus. He would create a series of registers that store pertinent data (motor postions, motor states, LED states, sensor states, alarms, etc). I would poll this frequently from the desktop to see if there are changes. Certain critical functions are handled automatically by the motors (example: if the film breaks, the motor will detect that torque is changed and will stop instantly)
With this setup, we are moving all of the logic into the desktop application, rather than having the ClearCore handle some multi-step processes. I personally prefer this, at least in principle, because I will know exactly what’s going on at any moment. But it also makes things a little more complicated for me in the front end app (rather than telling the controller “LoadFilm” I would need to send separate commands: enable the feed motor, enable the takeup motor, enable the capstan, lock the capstan, check the torque on the motors and potentially make adjustments.). Right now, I send a single command and wait for it to tell me we’re good. But the way it is now, if we need to make changes it needs to be done by the third party developer working on the firmware, which takes more time and costs money – and is difficult because it’s impossible to give that developer a duplicate machine (it weighs 500lbs).
So I am strongly inclined to try this new approach. The basic setup I’m imagining on the Xojo side would be a timer that runs very frequently (50ms maybe), and checks the clearcore for changes. All of the registers that the firmware guy exposes to me would be mirrored in my app as computed properties, so that I can react to changes in the register values when necessary. This is, in some way, similar to what I’m doing now with a few functions.
The devices being controlled by the ClearCore are:
- Feed Motor
- Takeup Motor
- Capstan Motor
- Camera Stage Stepper Motor
- Lens Stage Stepper Motor
- LED R-R-G-B-IR channels (5 channels total)
- Camera Stage front and rear limit sensors
- Lens Stage front and rear limit sensors
I guess my questions are:
- Is it feasible to run a timer at a frequency of 50ms? Can I go faster than that?
- Are there any obvious issues I might need to be aware of with a setup like this?
- In doing an operation like homing the camera stage (a linear stage controlled by a stepper, with a hall effect limit switch), I need to react immediately to stop the motor when the limit switch is triggered, because if I don’t the motor could send the stage too far. This works fine right now when done in the microcontroller, but I’m concerned that latency might be an issue doing this in a modbus setup.
Searching the forum, I saw there are some modbus tools available for Xojo, so we’d probably start there.