VAULT-SYS UPDATE - (CRON JOBS WORKING)
A sample of the progress I have made in the last week, I wanted to show it off for paid subscribers and curious free subscribers
I have not tested the Modbus process with a live connection to Modbus sensors in almost seven years. Embarrassing but true. Last live tests with Modbus were done in my garage in Melbourne, Victoria before my divorce. Even that was only for a single combination thermometer/humidity sensor, not exactly a real exhaustive test for the whole end-to-end process communication through the “post office.” (and that was in JSON messages, which run like a snail compared to the new ASN.1 bat-out-of-hell messages I am using now)
Prior to that in 2015 had been testing it with a massive array of Telstra hardware (Telecommunications company in Australia) batteries at their secure facility in Melbourne … I think it was colossal with something called “instancing” where I divided a single ID for a Modbus device into 100’s of separate measurements with a special modifier to the ID descriptor in the ASN.1 message. I was very proud of these tests, Telstra was pleased and everything was real-time updates on all aspects of charging for each of almost a thousand cells. It is hard to imagine a fallout shelter with that many batteries but the capacity will be there for pretty large scale monitoring based on those tests I did at Telstra. Could have just as easily been a thousand temperature sensors or water level sensors running with real-time display and alerts of changes to any of them. The only requirement is that they are all marked as the same configured device, it is only the “instance” that changes.
I had worked 8 weeks for these pitiful bastards at THYCON (through Christmas and New Year! Averaging 12 hour days, invoicing for 8, including Christmas Day!) and during that time had demonstrated my work for Telstra executives in meetings, run the continuous process 24/7 with all logging, recording and long-term charting functional and working. Database grew to a terabyte recording all measurements every 5 seconds for two months! Retrospective allowed you to know what a specific battery was behaving like at two minutes after midnight two months prior and plot it on a performance chart to see if it needed replacing. All colorful graphic displays in HTML browser. Beautiful application. A top-down real-time map allowed you to see the battery rooms and alerts flashing for a given cell on a given row on a given shelf with it’s current measurements floating as a tooltip! I was really proud of what I had accomplished, considering it was performing far beyond the demented specifications I had been able to wrestle out of THYCON. I was delighted to see my whole theoretical system clearly working under a big massive industrial load communicating across the Telstra installation with web browsers to the battery rooms. The problem was, THYCON had not paid me in 8 weeks on what was supposed to be weekly payments for invoices. My family was starving, we owed rent and I was still knocking it out of the park out at their client’s site. I called them on the morning of the third week in January and told them I was going to walk out if I was not paid by noon. At 12:01 nothing was in my bank account so I walked right off the site and quit on the spot until I was paid. I only got them to cough it up because I was getting ready to mail Telstra executives and tell them everything. A few of them had seen me working like a dog at midnight out there and it would not have looked good for THYCON at all if they knew I wasn’t even getting paid … because THYCON was getting their checks no problem!
It was a nightmare at the time … but thinking about it over the years, I realized the pinheads at THYCON actually subsidized the industrial scale testing of the VAULT-SYS architecture! THYCON actually became a big sponsor of research for American civil defense! All things work to the good of them that love God. It’s kind of funny to think about now. I might still not know if my design was going to work right under heavy loading if THYCON had not been such skinflint lowlifes. How does God keep track of all these parallel threads of execution with no race conditions? Truly an amazing coder and possibly the only entity in the universe who can really use Microsoft Project Planner to produce successful outcomes.
So that’s how I got here, to where I am now. A year late and plugging away. There’s one big difference. The former Modbus USB Adaptor with considerable support code required in the “daemon” process running alongside the server has now given way to a childishly simple connection to an RS-232 connection. Anything that continues to simplify any aspect of it is a good thing. With the speeds possible in RS-232 including virtual ports, my throughput through the message interfaces is guaranteed to run fast enough to handle anything a shelter dweller can come up with. (115200 baud pretty reliable short runs) If you want to know to the drop how much H20 you have left in thirty tanks, you can have level indicators reporting every time somebody has a glass of water.
My Modbus strategy moving forward into the first official version will be baby-simple RS-232 & RS-485 connections (virtual COM port on Windows, just as easy with driver) using these devices which have plunged in cost in the last 10 years! They used to be over a hundred bucks, now they run you around $12 I have been paying on EBay!
I cannot afford to test these now. I have to do that after I get my second version ready for review, which will likely be moving closer to a true release version. I have a setup now but it will delay first version until it is ready. So I am going with the Cron module as the first process to be controlled by the server, with many many modules coming for a long time afterwards.
My first process included with the server will be Cron which does test the messaging pretty reliably. The Cron job processor is edited from the HTML browser and communicates in the newly finished ASN.1 over mailslots. The Cron process can send and receive files via polling of HTML calls to REST services of another server, perform backups and system data logging. It’s not much at present but it’s flexible and can all be scheduled to run in the background so the server can do it’s usual client work without bogging down. No threads! Just processes communicating with each other.
The process itself, whether Cron or anything else (like a Modbus manager) can optionally send it’s output to a terminal VT-100 display or create a terminal window of it’s own. The flexibility is to permit separation of domains so that logging and monitoring for any given process can be abstracted away from the main server terminal window and sent if desired to another display device. So the goal is if you want to have your main server and browser running on one machine, you can have your processes in their own display on another monitor so you are not besieged by too much junk.
Below is just a cheap CRT monitor I got from a thrift store running a VT-100 terminal which is connected to COM Port #3 by a serial line. Although it is just simple text output to a console here, the VT-100 is capable of pretty sophisticated graphics using character sets like Codepage 437 for progress bars, windows, graphic controls, menus and more. Using this format as the default guarantees there is an upgrade path there to complex forms and other UI displays just sticking to serial line output. This permits the possibility that someday all processes could have a forms-based configuration or display that travels over serial, ethernet or other medium to transmit to remote devices. I blame a lot of these ideas on the last place I worked, which exploded the specification to a huge degree but got me thinking hard many years ahead. I wanted to see those goals way ahead to get me enthusiastic about the long term of working on VAULT-SYS until it does things that seem impossible. (Including sending interfaces to things at random to your “Pip-Boy” allowing you to operate things that could be miles away or right in front of you. I’ve got few tricks up my sleeve I am building into the architecture from the beginning so the finish will be incredible and more than was ever expected at the outset)
After all that faffing about message sizes and buffers, kind of ironic that the majority of all messages passed through the post office rarely exceed a few thousand bytes. It was still an important problem to solve for the occasional big message required. (Usually manifests the device sends to describe itself and all its properties for plug-n-play zero config operation.)
So this is a pretty good test of processes talking to the server and back round trip and it’s what I plan to demo in the first version. It’s a good enough module to debug for serious use and I hope to incorporate feedback from reviews to determine what other functionality could go into it that might be useful. It’s supposed to be a workhorse running in back of everything that does heavy lifting of drudge tasks like backups, file transfers, system logging and recording, etc.
Believe it or not, I am making steady progress and am getting there. Next update should show the main browser display and what that looks and behaves like for users.
Regards, Tex
I don’t have a tight grasp on what you have written about, despite reading every word, but it sounds beautifully interesting! 😃 Onwards and upwards Tex!👍
I generally dislike coding, but I'd be interested in configuring this for micro-hydro power generation control software. The main problem is I don't have a clue what I'm doing and I don't have any money, so it's sort of a pie in the sky at the moment.