Sharing Total Stations
You can count this as a bit of a beta product launch. We are trying to be a bit humble about it though, because, while one component is built, all the interlocking pieces are yet to come together into a final cohesive package. Over the coming months we’ll be able to release those products too, and you’ll all be the first to hear about it.
So, what we’ve been working on for quite a while is the total station sharing system called KodaTSShare. The version 1 prototype was finished months ago but it had its limitations. It was very good at handling two machines and sharing total station usage in a single work area. (In typical Koda style) even as we were finishing the code we were looking at the next generation system – the one we’re talking about today.
We’ll be implementing KodaTSShare as part of our underground construction package. Total station sharing is important as it allows multiple construction systems (roadheaders, rockbolters etc) to use a single total station while they are in the same working area. Rockbolters, which often move between different headings, simple log into the local TSShareServer and jump in the queue.
Each machine negotiates usage with the KodaTSShareServer and the server’s core process keeps the total station busy gathering and returning all the data to the KodaTSShareClient as soon as it is available.
Sounds simple…until you start to do it. We’re using TCP/IP over Wi-Fi to manage these more complicated systems. Note - for a simple, single machine system KodaTSShare will still be there, but it will be installed on the local machine and contacted directly via localhost – and no waiting in a queue as you’re the only one in it!
TCP Server/Client is reliable enough over Wi-Fi, but we’re not taking any chances. As we started building the system we realized there was a lot of work in merely ensuring all the connections were reliably maintained.
Once a client is connected to the server you have a full-duplex, two way connection. That’s great as the client can interact with the server and the server can interact with the client without caring about communications clashes and other implications. Combine this however with the non-deterministic timing of total station measurements and the processing of the measurement queue and you start to create some possible circumstances where things can get out of control – this is where we decided to implement the KodaTSShareClient as a state machine.
State Machines?
I’ll admit that when I first came across these during my Computer Science education in the late 90’s I thought: “are they really teaching us about cold-war era technology”. How wrong I was. Firstly, it was kind of fun. Lots of heart-ache too, especially working through state diagrams and AND/OR gates to solve a simple problem. However, once it was solved – it worked – and kept on working! The solution below is a hexadecimal counter circuit employing JK flip-flops and a couple of AND gates.
So, as much as a state machine can be used to design logical circuits it is also very common to use them to design and implement complex software. The major characteristic of a state machine is that the object only exists in one state at a time, and a set of narrowly defined interactions controls movement from one state to the next.
By implementing this behavior at the client end both the client and server can interact with each other on a more predictable playing field – with well-defined rules and messages.
How Aggressive Should I Be?
There’s often a decision to be made about how aggressive or forgiving your system should be. We’ve decided to make the server very aggressive in managing connections. If you connected and don’t register an alias within a certain period of time – you get booted. If you’re connected, and registered but don’t make a measurement request often enough – you get booted. This strategy ensures that stale or glitchy connections at either the client or server get dropped and replaced with new ones.
Final Word
I’d love to hear more about your experiences designing and writing code for complex systems, and don't discount yourself. You've probably done some of this more than you think, and believe me, Excel and VBA can create some very complex systems.
Please like, share, follow and we look forward to comments.
Until next time, KODA