The 80’s were simpler times, and life at that point was easy, and things worked well.. But then came the 90’s and along came Windows! I vaguely remember the 100’s of lines of weird C++ code, calling this API, then that API, just to get a window on the screen with “Hello world”, it all made zero sense at the time, not just to me, but a lot of our more traditional programmers, and I knew from that point on things had changed big time for me; I would no longer be a part of that world, I never wanted to see it ever again, and (for me at least) Windows/C++ had tainted the simplicity of C.

I guess this epiphany happened to a lot of other people too, as dozens of new programming languages, development environments, and operating systems, all sprung up around this time, each preaching a better and easier life than C/C++. My department however had committed to Windows, and we were all electronics engineers, so it was Visual Basic, then Delphi which won us over. Both languages hid the (high) complexity of Windows behind a simple event driven point and click interface, great for us engineers who simply wanted to get something done.

Someone coming into programming in 2026 will likely be offered JavaScript or Python as their first development language, both require an OS, an IDE, an interpreter or a browser, and probably the equivalent of a 1980’s supercomputer just to print “Hello World”. No beginner is really going to have a clue how their Print “Hello World” got onto their screen, because doing so requires understanding a API stack a mile high; If this was where I had to start my programming journey, I might never have begun, as I like to understand how things work. To many, I expect the inner workings of the stack between their chosen programming language, and the work their program actually does, is still black-magic.

I was lucky to have peeked behind the curtains early in my career, and have an intimate knowledge of CPU architectures, but even I have basically given up trying to understand the layers or stack. I read and write to whatever API is exposed, and hope the level below me knows what it is doing! Occasionally I have written parts of ‘the stack’, building hardware and writing a driver for Windows or Linux to support it, but even then I am conforming to a set of norms for the level above it, and I doubt anybody ever checked my code.

Only with Micro-controller projects am I fully back in control, and with them (for me at least) there generally was no stack; My program was the stack! This was however back with older 8-bit or 16-bit micros, and micro-controllers were not immune from technologies progress. Today’s micro-processors are amazing pieces of technology that have improved in leaps and bounds, going to multi-core monsters, with layers of complexity and peripherals that would shame a 1980’s super-computers. Unlike software though, they have done this while improving there efficiency and lowering there cost. For me, the best thing about all of this is you don’t really have to use any of this new complexity, and a simple blinking LED can still be done in a few primitive lines of C.

From a blinking LED I can add in all the complexity, and use as many of these new peripherals as I like. This is exactly like I did back in 1980 with my first Z80 chip, no real need for a stack or an API.

But API’s and stacks get added anyway, for convenience, reliability and speed of development. Abstracting away complex code behind a set of C SDK libraries, an RTOS, MicroPython, Arduino or even MMBasic, is a way of not having to learn the 1000’s of pages of CPU and peripheral datasheets. A lot of people are happy to take these easier options, including me, but lets not kid ourselves that we diligently read the libraries of source code that get compiled into our binaries, most of the time we are generally trusting the coders have done a good job.

A modern micro-processor, or System-On-Chip (SOC), is a far different beast from a micro-controller, adding many more layers of complexity, security, memory management, cores and peripherals, such as PCIe, USB3, Ethernet, or even a GPU. They are so complex that they often require there own bootstrap program to even initialise everything before it even finds and runs even a single line of your code. Very few programmers are brave enough to work bare-metal at this level because often as not these SOC’s, unlike micro-controllers, hide or abstract everything behind NDA’s or binary API’s, this is why for example on your cell phone, real world people accept they are going to work through an operating system and use the provided API’s.

So, to segue again back to my first paragraph, if I was being honest with my real goals, I love the fact that when working with micro-controllers I am effectively going back to a simpler time, a time where I owned, and understood the stack, where the stack hardly ever changed, and when I turned my computer on I was running my program code within microseconds. I guess that is why there is a resurgence in retro-computing going on, people still want to know what is behind the curtains and understand how it all works!

I am one of those people, but I will never go back to using a retro-computer or retro-operating system for my daily drive, I am happy the stack is there and hundreds of thousands of people have stood on each others shoulders, to bring me the marvelous Linux and IOS GUI’s I have today. However there is a cost, and that cost is complexity, efficiency, and the fact that programmers (like me) take all these layers of code for granted without looking behind the curtain. A whole Eco-system based on the trust that somebody else has done your due diligence for you!

This is especially scary once you realise how many bad actors are out there, examining every line of these stacks for code vulnerabilities. This is happening every hour of the day, and they are finding them with ease. AI, over-complicated programming styles, and dependency hell, are making it harder for the developers to miss these cracks in their code reviews, and easier for the bad guys to find them.

Hacker News Link and Comments For Story Above

Unfortunately, as always, it is up to you to balance the security, against the ease and convenience, or, like the vast majority of us, believe the myth that your system is secure and does not have these problems.

Thanks to Gemini for the memes, but like AI vibe-coding it pays to look at the finer details

The vulnerabilities of these programming stacks were one of the plot elements in my free sci-fi trilogy eBook The Summer Of Reasoning. I still think I did a good job in that book of explaining the problem, why it matters, and the consequences of when it fails.

Wake up time from sleep is as good as my old windows, as is startup from cold. The advice from my AI guru Gemini has surprisingly continued to be concise and accurate, with none of the condescending, “RTFM” or “you must be a fucking retard” answers you obligatory got with every question asked on reddit or stackoverflow. So no show stopping issues, but a few annoyances.

Annoyance 1. (edit – fixed itself) When you click on the Thunderbird email shortcut, it shows the program start to run (cursor changes to Thunderbird icon briefly) but no window appears, then I wait a few seconds try again and the same thing happens, third time you do it the application pops up. The email data is on a different partition of the SSD which I do mount at boot, but AI seems to think it is something to do with a thing called “snap” a security-sandboxy-thing that Kubuntu implements. I generally only read my email once in the morning now, and everything I get is spam so not a biggy, just an annoyance, that doesn’t seem to happen with the other apps.

Annoyance 2. (edit – fixed) Window sizes and defaults. The monitor I work with for writing documents is off to the left of my main monitor and is orientated in portrait, the main one (same model hardware) is landscape. A couple of times writer has opened on the landscape monitor with the position way off the top of the monitor so I cannot see or access the menus. The first time I saw this I assumed it had crashed by not redrawing the menus, but they were all hidden off the top somewhere. Right clicking the icon on the taskbar allows you to recover from this annoyance, and my AI Bestie says I can configure a “special application setting” which looks easy, but other apps seem to remember so it might just be LibreOffice.

Annoyance 3. I plugged an RP2040 microprocessor development board into my ThinkPad dock, all worked fine as expected, but when I unplugged it, the USB on the dock failed and my mouse and keyboard would not respond. The ThinkPad keyboard and track-pad however still worked, unplugging the docks cable and plugging it back in did not fix it, but a reboot did. I did not get the same issue when I plugged the development board directly into the laptop.

So much with the minor annoyances, I am already over them, my Bestie’s recommended fixes worked fine, and I am totally stoked by how much just works properly ‘out of the box’. Now lets get onto whats better.

Lazarus/Free Pascal was always a second-tier programming language to Delphi as all my major client production systems were written in Delphi. I will not be re-creating a 200,000 line winery production system in Lazarus as it would take forever and I doubt anybody would want it anyway, but I do have a lot of small utility programs written in Lazarus and compiled for Windows. Lazarus is a fast developing system and the packages on Kubuntu are out of date, but the install is quite clear to download the latest stable deb packages and install them using the CLI (Command Line Interface – See I’m becoming a geek already!) This worked fine and added Lazarus to my programming start menu, and it all started without issue. The major issue to convert my programs are to change the widget sets from Win32 to QT5 which was simply an options change, and my first hello world program was 3 minutes later.

My last thing to test is my VS Code C programming environment, however I might take the opportunity to move to a simpler / more Linux friendly option as I have no current projects I need to work in C.

Update 28 Jan 2026

As you can see above, a few of my original annoyances have already been solved, though I am not plugging my PICO into the hub again just in case. For my C development environment I went with VSCodium (a version of VSCode minus the Microsoft specific stuff) as I am at least familiar with that IDE and it seems to be the best supported for ESP32/RP235x my two current micro’s of choice. Both SDK’s loaded and LED’s blinked, and the VSCode environment feels the same bloated and confused as it did in windows.

So all is going well, the BIG downside to Linux in the past was the command line stuff, which seemed to change with the season, or whatever new program, environment was in vogue. But I find I am not going into it much and that BASH hasn’t changed much in the last 30 years, so at least I can navigate around most things, and understand the commands that the AI is telling me. Of course if I don’t understand then I can at least now get anything explained or read the referenced documents; This seems like a better way to work.

Well this my friends was an 8051 developers board; Part of the extremely expensive Intel 8031/8051 developers kit, which several of the GCHQ development (M Division) departments used back in the day. This kit usually included an in-circuit emulator (ICE), some sort of flash programmer, a wad of thick manuals, and the complete software package for VAX/VMS (The OS of champions back in the day!). The Intel 8031 was basically an 8051 without flash or EPROM and a lot less expensive, it was usually paired with something like an 8755 EPROM/IO.

Now in the early 80’s adding any type of smarts to your electronics project was not quite as simple as connecting a $2 board and running up an Arduino IDE; Back then the world was mostly focussed on micro-computers such as the Z80, 680x, 650x, etc, which required all the associated RAM/ROM and IO to make them work. Micro-controllers were there but hidden from the normal hobbyists, and used mainly in industrial applications. The first microcontroller I was exposed to was the 8031, and like many things, once I got used to it, I just stuck with it. The 8051 is still used today.

An 8051 in the mid-80’s cost about US$40 (US$90 in 2025 money), though that was not the end of it, back then you also had to buy or pirate the assembler or compiler software, and, to put the proverbial nail in the coffin, buy or have access to an EPROM programmer. As a twenty year old junior technician I was always wanting to build things, but I was also perpetually broke, had to pay rent, run my car, eat and drink too, so forking out mega-bucks for the above was never going to happen. Luckily I worked at GCHQ!

There is a bit of a little known fact about GCHQ (and I guess all military/NATO organisations should be included here) and that is a lowly junior electronic technician back then could simply write out a chit, with a NATO stock number on it for almost any electronics part, and it would magically appear the same or the next day; With almost no questions asked! Also as an electronics technician, when we weren’t repairing or servicing computers (which was most of the time) we had very little to do.

Being in a maintenance department we did not have the full development kit, nor a spare VAX in the office to run it on (We fixed mostly DEC PDP 11/70s and peripherals). What we did have though was a PC/XT, a EPROM blower, wads of time, and an almost infinite supply of components! Coding back then for a poor hobbyist meant getting the data book, writing out all the op codes by hand, typing the resultant hexadecimal into a file and sending it to the EPROM blower to write the 8051 or 8755! But yours truly also had a secret weapon, TURBO PASCAL!

Writing an assembler was simply substituting 8051 assembly mnemonics for there hexadecimal equivalent, and remembering a few labels so you could add in the appropriate memory locations, registers and jumps, it certainly wasn’t rocket science. That is exactly what 1984 Boz thought and so he wrote one.

I am pretty sure this was one of my very first Pascal programs, as I started using Turbo Pascal 1.0 in September 1984 after another guy Mark loaded his copy on the work PC and showed me it. I also used the newly written assembler to program my home built 8031 based central heating controller which would have been Christmas that same year. The big surprise from Tony’s email was that he had kept a copy of that assembler program, as he was going to use it to determine how to write a Z80 one. More importantly, he also kept a copy of it’s turbo pascal source code. The really big surprise is that in 2025 it all still works!

The code is laughable (from the perspective of 2025 Boz), but I had to remember that back then Turbo Pascal compiled to the old COM style executable, not the EXE, and so code and data had to fit into a 64KB memory segment. I had never done any formal programming courses, had never used an assembler, nor had any idea how an assembler worked until I decided to build one. So I basically guessed how to do it, assuming I could define registers or memory addresses with labels, and use labels for jumps, just like hand written stuff. What a trip down memory lane..

The 660 lines of pascal I wrote also included an interface to the EPROM programmer we used at the time, and all compiled to a 24KB executable! As you can see from the program comment it was seriously limited (having only 26KB free for data), but you also have to remember, the 8051 had only 2KB of memory and 128 bytes of RAM back then! Luxury!

I have attached the whole project zip to my google drive. This 55KB zip file not only contains the assembler pascal source code and executable file but also the whole turbo pascal 3.02 IDE. (Turbo Pascal 3 was made free back in 2002) Everything runs fine on the date of this post on the latest DOSBox

Remember this was 1984 and young Boz had never seen a proper assembler, I hand-coded stuff from listings in computer magazines, and the made-up syntax of the source file was probably influenced from my exposure previously to BASIC programming. The assembly file below contained all the supported op codes to test the program worked properly.

DATA=$AA
PSW=50
RGR21=20
BITST=$50
RGR20=$20
TEST=255

ORG $0000
START:   ADD A,R0
         ADD A,R1
         ADD A,R2
         ADD A,R3
         ADD A,R4
         ADD A,R5
         ADD A,R6
         ADD A,R7
         ADD A,#DATA
         ADD A,@R0
         ADD A,@R1
         ADD A,RGR20
         ADDC A,R0
         ADDC A,R1
         ADDC A,R2
         ADDC A,R3
         ADDC A,R4
         ADDC A,R5
         ADDC A,R6
         ADDC A,R7
         ADDC A,#50
         ADDC A,@R0
         ADDC A,@R1
         ADDC A,RGR20
         ANL A,R0
         ANL A,R1
         ANL A,R2
         ANL A,R3
         ANL A,R4
         ANL A,R5
         ANL A,R6
         ANL A,R7
         ANL A,@R0
         ANL A,@R1
         ANL A,#TEST
         ANL RGR20,#TEST
         ANL RGR20,A
         ANL A,RGR20
         ANL C,RGR20
         CJNE A,#TEST,START
         CJNE A,RGR20,START
         CJNE R0,#TEST,START
         CJNE R1,#TEST,START
         CJNE R2,#TEST,START
         CJNE R3,#TEST,START
         CJNE R4,#TEST,START
         CJNE R5,#TEST,START
         CJNE R5,#TEST,START
         CJNE R6,#TEST,START
         CJNE R7,#TEST,START
         CJNE @R0,#TEST,START
         CJNE @R1,#TEST,START
         CLR A
         CLR C
         CLR RGR20
         CPL A
         CPL C
         CPL RGR20
         DA A
         DEC A
         DEC R0
         DEC R1
         DEC R2
         DEC R3
         DEC R4
         DEC R5
         DEC R6
         DEC R7
         DEC @R0
         DEC @R1
         DEC RGR20
         DIV AB
LL1:     DJNZ R0,LL1
         DJNZ R1,LL1
         DJNZ R2,LL1
         DJNZ R3,LL1
         DJNZ R4,LL1
         DJNZ R5,LL1
         DJNZ R6,LL1
         DJNZ R7,LL1
         DJNZ RGR20,LL1
         INC A
         INC DPTR
         INC R0
         INC R1
         INC R2
         INC R3
         INC R4
         INC R5
         INC R6
         INC R7
         INC @R0
         INC @R1
         INC RGR20
         JBC BITST,LL1
         JZ LL1
         JB BITST,LL1
         JC LL1
         JMP @A+DPTR
         JNB BITST,LL1
         JNC LL1
         JNZ LL1
         LCALL SUBRT
         LJMP LL1
         MOV DPTR,#$AAAA
         MOVC A,@A+DPTR
         MOVC A,@A+PC
         MOVX @DPTR,A
         MOVX A,@R0
         MOVX A,@R1
         MOVX @R0,A
         MOVX @R1,A
         MOV A,R0
         MOV A,R1
         MOV A,R2
         MOV A,R3
         MOV A,R4
         MOV A,R5
         MOV A,R6
         MOV A,R7
         MOV A,@R0
         MOV A,@R1
         MOV R0,A
         MOV R1,A
         MOV R2,A
         MOV R3,A
         MOV R4,A
         MOV R5,A
         MOV R6,A
         MOV R7,A
         MOV R0,#TEST
         MOV R1,#TEST
         MOV R2,#TEST
         MOV R3,#TEST
         MOV R4,#TEST
         MOV R5,#TEST
         MOV R6,#TEST
         MOV R7,#TEST
         MOV R0,RGR20
         MOV R1,RGR20
         MOV R2,RGR20
         MOV R3,RGR20
         MOV R4,RGR20
         MOV R5,RGR20
         MOV R6,RGR20
         MOV R7,RGR20
         MOV @R0,A
         MOV @R1,A
         MOV @R0,#TEST
         MOV @R1,#TEST
         MOV @R0,RGR20
         MOV @R1,RGR20
         MOV A,#TEST
         MOV A,RGR20
         MOV RGR20,#TEST
         MOV RGR20,A
         MOV RGR20,R0
         MOV RGR20,R1
         MOV RGR20,R2
         MOV RGR20,R3
         MOV RGR20,R4
         MOV RGR20,R5
         MOV RGR20,R6
         MOV RGR20,R7
         MOV RGR20,@R0
         MOV RGR20,@R1
         MOV C,BITST
         MOV BITST,C
         MOV RGR20,RGR21
         MUL AB
         NOP
         ORL A,R0
         ORL A,R1
         ORL A,R2
         ORL A,R3
         ORL A,R4
         ORL A,R5
         ORL A,R6
         ORL A,R7
         ORL A,@R0
         ORL A'@R1
         ORL A,#TEST
         ORL A,RGR20
         ORL RGR20,#TEST
         ORL RGR20,A
         ORL C,BITST
SUBRT:   POP PSW
         PUSH PSW
         RETI
         XRL A,R0
         XRL A,R1
         XRL A,R2
         XRL A,R3
         XRL A,R4
         XRL A,R5
         XRL A,R6
         XRL A,R7
         XRL A,@R0
         XRL A,@R1
         XRL A,#TEST
         XRL A,RGR20
         XRL RGR21,A
         XRL RGR20,#TEST
         RET
         RL A
         RLC A
         RR A
         RRC A
         SETB C
         SETB BITST
         SJMP HERE
HERE:    SUBB A,R0
         SUBB A,R1
         SUBB A,R2
         SUBB A,R3
         SUBB A,R4
         SUBB A,R4
         SUBB A,R5
         SUBB A,R6
         SUBB A,R7
         SUBB A,@R0
         SUBB A,@R1
         SUBB A,#TEST
         SUBB A,RGR20
         SWAP A
         XCH A,R0
         XCH A,R1
         XCH A,R2
         XCH A,R3
         XCH A,R4
         XCH A,R5
         XCH A,R6
         XCH A,R7
         XCH A,@R0
         XCH A,@R1
         XCH A,RGR20
         XCHD A,@R0
         XCHD A,@R1
         XRL A,R0
         XRL A,R1
         XRL A,R2
         XRL A,R3
         XRL A,R4
         XRL A,R5
         XRL A,R6
         XRL A,R7
         XRL A,@R0
         XRL A,@R1
         XRL A,#TEST
         XRL A,RGR20
         XRL RGR21,A
         XRL RGR20,#TEST

I did also go on to write a compiler for an 8031 called BPL (Boz’s Programing Language – go figure!) it was a weird cross between Turbo Pascal 1.0, BASIC and C. Unfortunately I have not seen it for about 15 years, but I will find it one day.

Comments here => Do 8051/8031 assembly like its 1984 | Hacker News

My second language was Turbo Pascal 1.0 on the IBM XT/DOS, this more than anything made me realise I could literally do anything on the machine at amazing speed. I solved all sorts of complicated problems building everything from 8031 assemblers to a complete satellite communications-centre monitoring system, none had performance issues despite being limited to a 4.7Mhz 8088. I also wrote simple CGA games, and as a side note I remember about 15 years ago finding an old 32KB file called space.com, which when I ran on FreeDOS simply flashed the screen and went back to the DOS prompt. After scratching my head for several minutes I found a way to tweak the clock speed down and saw it come up with the opening screen of the pascal space invaders game I wrote; It played the demo game to the end (while waiting for input), and when the demo finished closed the program, all in under a second.

I still love and use Pascal in the form of Delphi and Lazarus/FreePascal, in fact the last two production systems I wrote controlled the whole MRP/ERP environments for large companies for 16+ years without any incidents, and the only red flags the auditors could ever point to were 1. Obsolete technology (fuck off Deloitte’s!) and 2. Single-man risk, which I guess they had a genuine point with.

As I mentioned, one of my first Turbo Pascal programs was an 8031 assembler, as, being an electronics engineer I was primarily designing with microcontrollers. Tools in the 80’s were expensive, all of the microcontrollers I worked with then used C and UNIX for the compiler, so I reluctantly also learned C. I have always had a love/hate relationship with C, I loved the fact I had so much control over the hardware, in (mostly bad) ways that Pascal would almost never let you get away with, but I hated how it came with the double-edged sword of readability, horrible header files, and slower and slower compile/link times even as the hardware improved.

But in 1989 there was a missing component in my programming war-chest, one I had been compensating for unknowingly by writing and incorporating it myself into most large programs I wrote; A database. My exposure to IBM DB2 and SQL was, like C, forced upon me by my job. It turned out management and colleagues did not like their data stored on disk in a proprietary file structure and so I was put on an SQL course. SQL was an eye-opener, and of course gave me access to such things as other-peoples tables, so I no longer needed to store things like names and addresses I could use the account table in the common database and everyone could write reports on my data. SQL filled the gap that Pascal had on the top of the stack, C filled the gap at the bottom, and by the mid-90’s I was in programming nirvana.

It is now the end of 2025 and these are still the three primary languages I develop in, as they do everything me and my clients wanted. I get frustrated in all three, but I work around the frustration, and the FUD, and get straight back into using them to make things.

There is a really big downside to not upskilling to the latest language every decade or so, and that is it drastically lowers your desirability to employers in the market. You have to balance that however with a big upside, and that is when you have been using something for ten or more years, you know its faults, and exactly what it is capable of. I can totally understand why people move with the current trends, you do need to follow the money while you can; However, and if you are realistic with yourself, it is almost 2026 and really only a matter of time before AI papers over all those little cracks it currently has, and truly delivers on the promise of vibe-coding. So the question now becomes, do you really want to learn that new language and become a newbie again at this late a stage?

Its a rhetorical question, I don’t expect you to have an answer, and to do what is right for you at the time, but as a thought it is interesting to ponder.

I doubt any of this will matter much for me, as although I have always been able to produce the same results the big boys could with their state-of-the-art stacks, no company is realistically going to ask me to write their new MRP system in 2025 in Pascal! Still, my other two programming skills are still trendy, so I guess I should be able to cruise into retirement sunset on the coat-tails of SQL or C – Though, and if I am honest, with only 35 years of C under my belt I still consider myself to be a newbie!

Posted to Hacker News here, I do read the comments (eventually!)

Me, Allison (Winemaker) and Fran (transformation project manager) overlooking the Indevin Winery floatation system and three of its four float pools

This post will concentrate on this floatation process, or more specifically the continuous floatation process, and how your wine-making system should keep track of the composition. A very simplified diagram of this process is below. Where multiple Crush tanks with compatible juice are successively fed into the pool until the clear tank is full.

Note in the text below we might see reference to a propagation or “Prop” tank, this is just another clear tank with a different name and a different status and the procedure to get its composition is identical.

When processing just a single crush tank, we fill the float pool from the crush tank (yellow in picture), and once the pool is full we begin bubbling the gas through, collect the clarified juice from the bottom (blue in picture) into the clear tank, and the rest (the grey in the picture) is considered lees and goes to the lees tank where it is either further clarified to get a bit more juice or disposed of. Once the crush tank and float pool are empty we start again.

The problem with this (single) float is we have to stop the process to empty the pool, which can add some hours to the procedure. In a continuous floatation process when the first crush tank is emptied, we record the tank dips, and flowmeter readings, while the float pool is still full and change to a new crush tank and continue the process with minimal interruption, eventually after processing several similar crush tanks the last job empties the pool and the sequence restarts with the next batch.

Obviously with this continuous system it is still vital to keep track of the composition of the wine for food safety and regulatory requirements. Because the float pool is much smaller than the size of the crush tank we can make a couple of important assumptions verified by measurements:

1. The juice volume left in the float pool from the last crush tank will be completely replaced by the juice from the next crush tank.
2. The volume that goes into lees will be the crush volume minus the clear volume.

To work this into a system we need to be able to capture the volumes in and out of the pool, which we do using a flowmeter (FM1) on the inlet of the pool from the crush tank and another (FM2) on the clears line. There is no point in putting a flowmeter on the lees line, as the volume is mainly particulate and foam and confuses normal flowmeters which require liquids. Generally lees volume is 6% of the crush total, but this is an average based on an average juice, and there is no such thing as one vintage may produce differing results. So at the end of each crush tank we have

FM1 = Crush Volume 
FM2 = Clear Volume 

Lees Volume = FM1 - FM2

The float pools also have a nominal (full) volume we work to and in practice the inflow and outflow is controlled to keep it at this volume throughout the process.

For the system we designed we split the continuous floatation into jobs based on the emptying of a crush tank. At the start of each job we will have the known start volumes of the crush and clear tank (via DIPs or otherwise) and our first action is to ensure both the flowmeters are reset so we can do the calculations. This I do quite easily as I already have a bi-directional service connecting the SCADA systems to MySQL (the Bulls-i RDBS) plus I keep my own counters for both flowmeter values independent of the values held in SCADA as these can be reset manually and I have been burnt many times by using other peoples data.

We have three possible types of continuous floatation jobs, the first where we fill the pool, then one or more middle jobs, and finally an end job where we flush the pool and this can be seen in a simple series of jobs below.

In the first job in the series where we fill that tank we only have one source “SRC #1” and all the juice volume will end up in either

1. The Float Pool (at the Float pool fill volume)
2. The Clear/Prop tanks (Volume Determined by FM2 and the Initial and Final Dips of the tanks)
3. The Lees Tank (the remainder with the “dirty” juice)

This is a normal job, one-to-many and fits in nicely with the current winemaking job system.

For the middle job(s) in the series however it becomes a bit more complicated as we have two source vessels “SRC #2” and “Float Pool #1” and two or more destination vessels as per the previous case. This situation cannot be processed as a normal job which must be one-to-many, or many-to-one to create a composition. to fix this at the end of the job we need to create two jobs.

The first job is a prequel job to transfer (flush) the volume of “Float Pool #1” to the clear and the lees, this will also alter the volumes of the two tanks which we need to ensure are the start volumes of the second job. The second job is the same as the first job in the series where we again fill the pool from the source and have balances go to clear and lees.

The final job in the series where we empty the float pool again has two source tanks, but the only difference with this one is that at the end of the job, all the volume in the float pool is flushed out to the clear and lees vessels so ending the sequence.

In the Bulls-i system “Float Pool #1” is an asset, but it is NOT a tank. However as a programmer, I can bypass this restriction and so treat it as a virtual tank, giving it volume, batch-codes and a composition exactly like a normal vessel and knowing that at the end of the series it will be empty.

So not a difficult process when you break it down into steps.

There are two users of the system, the winemaker who creates the floatation jobs and decides on which tanks and float pools will be allocated, where they go in the sequence, and what additives if any need to be made. The other is the cellar-hand who operates the system and does the work on the winery floor, and who needs to see the current status of the job clearly and be able to enter information on a system to say which tanks are connected and their opening and closing volumes.

The winemaker part of this is shown above (for “Pool B”) Only one job can be active in a line, and we must have at least a FIRST (to fill the pool) and a LAST (to empty the pool) along with 1 or more MIDDLE jobs. The Winemaker job screen looks like below

This job translates onto the Cellar-hand operators touchscreen as below where we have a very limited number of options to start the job, make product additions to the tank/pool and start and end each tank in series. The operator screen will also require RFID confirmations from operators who have the qualification to do this. In this way the winemaker fills the operators work buffer and when the operator has finished and signed off the job it is returned to their office screen to complete.

All the flowmeter and SCADA volumes are captured and displayed real-time on the appropriate graphic on the screen to aid both the winemaker (sitting remotely in an office) and the operator doing the job. There are also a few additional toys we have added to this system to reproduce the four (RED/GREEN/YELLOW/FALSHING) LEDs from the program to real lights on the cellar floor.

Hopefully this brief introduction to automating a slightly more complicated production process will show what is possible.