Anyone work in tech?

"Argos"? Is that the satellite "System Argos" or something else? Heartbeat and watchdog timers! Old friends indeed - you're doing fault tolerant programming there. I don't know enough about your system - which looks impressive to me - to be able to tell how this runs - but I found years back that software heartbeats and watchdog resets need to be as far in the foreground/upper level as possible as background/lower level watchdogs had an annoying tendency to keep working just fine even though the foreground had crashed and the system wasn't doing what it was supposed to.
 
"Argos"? Is that the satellite "System Argos" or something else? Heartbeat and watchdog timers! Old friends indeed - you're doing fault tolerant programming there. I don't know enough about your system - which looks impressive to me - to be able to tell how this runs - but I found years back that software heartbeats and watchdog resets need to be as far in the foreground/upper level as possible as background/lower level watchdogs had an annoying tendency to keep working just fine even though the foreground had crashed and the system wasn't doing what it was supposed to.

Argos is my company's internally developed cloud-based data acquisition system that allows for us and our customers to log in and remotely check in on equipment, change parameters, view and download trends for diagnosis, etc. We have a piece of hardware that temporarily stores data read from the Modbus server on my controller, then uploads it to the cloud server via the cellular modem. Depending on the quality of cell service at the site, sometimes the cell modem loses connection and will stop re-attempting. The server writes a 1 to my controller periodically, I wait 10 seconds and write a zero to that variable (the "heartbeat"); if it stays zero for 30 minutes (indicating the server can't reach me through the cell modem), I "defibrillate" by opening a set of relay contacts that interrupt power to the modem for 1 minute.
 
I am old enough to remember telling someone to learn to code got you the ban hammer.


200.gif
 
  • Like
Reactions: RINC
Argos is my company's internally developed cloud-based data acquisition system that allows for us and our customers to log in and remotely check in on equipment, change parameters, view and download trends for diagnosis, etc. We have a piece of hardware that temporarily stores data read from the Modbus server on my controller, then uploads it to the cloud server via the cellular modem. Depending on the quality of cell service at the site, sometimes the cell modem loses connection and will stop re-attempting. The server writes a 1 to my controller periodically, I wait 10 seconds and write a zero to that variable (the "heartbeat"); if it stays zero for 30 minutes (indicating the server can't reach me through the cell modem), I "defibrillate" by opening a set of relay contacts that interrupt power to the modem for 1 minute.
Ok - completely different Argos. Good solution with your MODEM. MODEMs of all sorts are problematic to keep running. I've used an automatic power cycle on my various MODEMs for literally decades, turning off the power for a minute or two in the middle of the night. Sometimes it was computer controlled, sometimes just a simple mech timer if an asynchronous reboot wasn't problematic. I reset my Wi-Fi MODEM/Router this way to this very day and have far fewer problems with it as a result.

Many, many years ago, I ran a dial-up BBS, which had all sorts of fault tolerant things built into it, including MODEM reset under its control (so it wouldn't boot an active user off), as well as two separate watchdog timers. Before I put the power control on, the MODEM would be locked up once or twice a week. Afterwards, basically never. The Loma-Prieta earthquake hit on 17 October 1989. Of the 8 or 9 local BBS systems that were affected, only TWO came back up automatically 2 days later when the power was restored. Mine was one of them, the other was a Christian BBS with unknown hardware. I don't know if he had a similar setup or just was lucky. The dirty powerup crashed the MODEMs and/or the computers on the rest of them, and they didn't come back up until their SYSOPs were able to get to them to do a manual intervention - some were down for over a week! I also automatically rebooted the computer daily (even back then Microsoft liked to be rebooted regularly) - there was a huge 3AM event that would turn off the power to the MODEM, do some house keeping, then reboot via a hardware port. When the system came back up, it would power up the MODEM, then initialize the BBS and life was good!
 
I'm a retired software engineer. I worked as a government contractor on large, enterprise scope, data management systems for the US government for about 30 years. I quit just a couple years ago.

Crappy software is the norm these days. In some shops, they let the millennials run the show and not to overgeneralize too much, but many/most seem to be more interested in playing with shiny new bleeding edge technology than actually solving problems or supporting the actual mission. Drove me nuts. Constantly battling problems with immature technology or technology that was simply a bad fit for what was needed.

Another problem is that tech jobs are plentiful and pay well where other segments of the job market are crap. My daughter in the bay area has told me that, as a result, several of her college grad friends have abandoned their original career goals to get into IT/software/etc. So now you have people who have no real interest and probably no talent trying to support complex IT/software systems and develop nightmare software that some poor schmuck will have to maintain.

This is actually somewhat similar to when I got into the field. Most of the people developing software at the time were actually educated as electrical engineers with no formal training in software. Their code as a general rule was sorely lacking to put it nicely. I was lucky enough to have had recent, current education and a computer science degree when such a degree had not existed for very long. And at that time, new technology in the software/IT field was not being created nearly as fast as it is today. So the shiny object syndrome was less of an issue.

I planned to work until I reached 65 but couldn't take it quite that long and retired a few months early. No regrets.
 
but many/most seem to be more interested in playing with shiny new bleeding edge technology than actually solving problems or supporting the actual mission.
This is my biggest complaint of many of my peers, it causes a lot of issues and requires writing a bunch of boiler plate code to solve the already solved problems.

I enjoy solving problems, but Ive considered changing careers because of the general culture leaking out from the bay area
 
  • Like
Reactions: Zorba
Im no where as deep into the code as you guys, but my daily grind is as an Applications Engineer for an LED lighting manufacturer.
I get to spend my days listening to angry customers, disgruntled electrcians/installers, ignorant designers, and terrible drafters all tell me that our product doesn't work as expected.
The typical reply involves a response like, "that's not what the drawing shows", "please perform these tests and tell me the results", or "do you have an actual electrcian on site"?

Most of my day involves a lot of waiting around for the next angry email or phone call telling me that the sky is falling because the lights don't respond to a 3rd party control system, etc. and a lot of internet research for my various side projects (including the Jeep, the Harley, the Charger), or previewing our next vacation destination.
 
I enjoy solving problems, but Ive considered changing careers because of the general culture leaking out from the bay area

Well, don't move too fast. The shiny object syndrome is not at all unique to the bay area. The bay area is mostly commercial work where bad technical decisions hurt the bottom line.

I worked mostly on the east coast near DC as a government contractor and the shiny object syndrome is rampant in that arena. I saw almost no accountability for bad technical decisions. On most programs I worked on, political maneuvering outweighed technical considerations by a large margin.
 
Well, don't move too fast. The shiny object syndrome is not at all unique to the bay area. The bay area is mostly commercial work where bad technical decisions hurt the bottom line.

I worked mostly on the east coast near DC as a government contractor and the shiny object syndrome is rampant in that arena. I saw almost no accountability for bad technical decisions. On most programs I worked on, political maneuvering outweighed technical considerations by a large margin.
Fortunately I don't and wouldn't live there, I live in Colorado. I would like to see more accountability for bad decisions, unfortunately people generally move jobs too much anymore.
 
  • Like
Reactions: WestCoastDan
I live in Colorado

No immunity from the shiny object syndrome there either. A lot, probably most, of the tech work in CO is US government contracting.

My last gig was working for a CO Springs company on an Air Force contract. Terrible technical decision making on that program and no accountability at the company or the government levels. All politics. That project drove me to early retirement.
 
Good on you. Nobody gives a damn about this stuff much anymore.

it occurs to me that my most common screw-up is related to data types. I always default to 8 bit.

My customer is often short sighted and will give me requirements based on the next site when I ask for the maximum requirements of ANY site. So they tell me I'll have about 6 different on/off devices that add refrigeration capacity, and I write a program that will handle 8, where the possible combinations of on or off is 2^8=256 (0-255), and I use an 8 bit unsigned integer.

Then a couple months later, the next system has 10. I forget that's an 8 bit integer and after a couple of days we notice one of the compressors has never turned on, which is pretty weird. Took me a few minutes to figure it out but then I was like, oh yeah, those two devices don't have a bit to turn them on. Gotta make that one 16 bit.
 
it occurs to me that my most common screw-up is related to data types. I always default to 8 bit.

My customer is often short sighted and will give me requirements based on the next site when I ask for the maximum requirements of ANY site. So they tell me I'll have about 6 different on/off devices that add refrigeration capacity, and I write a program that will handle 8, where the possible combinations of on or off is 2^8=256 (0-255), and I use an 8 bit unsigned integer.

Then a couple months later, the next system has 10. I forget that's an 8 bit integer and after a couple of days we notice one of the compressors has never turned on, which is pretty weird. Took me a few minutes to figure it out but then I was like, oh yeah, those two devices don't have a bit to turn them on. Gotta make that one 16 bit.
Byte vs word. Integer vs float. Single vs double precision. And then there's radix. All have taken a chunk outta my ass at one time or another. Let's not discuss Intel's bullshit segmented architecture - any time I stare at code that should work but doesn't, its a segmentation error!
 
I'm a software engineer building trading systems for a cryptocurrency exchange, about a decade into the career now. I've done frontends too but mostly settled into the backend side as I never liked how the front end tooling had so much turnover.
I’ve been in the low latency trading infra side for 10+ years. Started in Futures&Options, FX and then Equities. Now at a low latency edge compute company. Hit me up if you (or anyone else) wants some low latency compute capacity. Happy to hookup anyone on the forum.
 
  • Like
Reactions: rasband
I'm a retired software engineer. I worked as a government contractor on large, enterprise scope, data management systems for the US government for about 30 years. I quit just a couple years ago.

Crappy software is the norm these days. In some shops, they let the millennials run the show and not to overgeneralize too much, but many/most seem to be more interested in playing with shiny new bleeding edge technology than actually solving problems or supporting the actual mission. Drove me nuts. Constantly battling problems with immature technology or technology that was simply a bad fit for what was needed.

Another problem is that tech jobs are plentiful and pay well where other segments of the job market are crap. My daughter in the bay area has told me that, as a result, several of her college grad friends have abandoned their original career goals to get into IT/software/etc. So now you have people who have no real interest and probably no talent trying to support complex IT/software systems and develop nightmare software that some poor schmuck will have to maintain.

This is actually somewhat similar to when I got into the field. Most of the people developing software at the time were actually educated as electrical engineers with no formal training in software. Their code as a general rule was sorely lacking to put it nicely. I was lucky enough to have had recent, current education and a computer science degree when such a degree had not existed for very long. And at that time, new technology in the software/IT field was not being created nearly as fast as it is today. So the shiny object syndrome was less of an issue.

I planned to work until I reached 65 but couldn't take it quite that long and retired a few months early. No regrets.
Ha ha! I'm one of those EEs! I got one class in FORTRAN 66 and away I went. Learned PDP-8i and 9 assembly language to work on a Navy system. Had to learn Univac 1106 / 1108 assembler for another project. Bought three IBM PCs for work in 1979, so had to learn BASIC. Learned C when I went to work for a new company building RF modems that used cable-TV system infrastructure (in 1980). Learned Visual C++ to build a check ordering system. BTW, I hate software! Finally got into the infrastructure side and did a bunch of data center relocations, DBMS upgrades, and general equipment upgrades. Designed two-way mid-split cable systems for most university campuses. Moved from engineering into project management in mid-'90s and worked up to VP PM. Retired in 2020. I do miss having a couple of hundred folks working on a large project team, but I don't miss the stress of managing budgets, timelines, personnel, vendors, and especially finance.
 
Ha ha! I'm one of those EEs! I got one class in FORTRAN 66 and away I went. Learned PDP-8i and 9 assembly language to work on a Navy system. Had to learn Univac 1106 / 1108 assembler for another project. Bought three IBM PCs for work in 1979, so had to learn BASIC. Learned C when I went to work for a new company building RF modems that used cable-TV system infrastructure (in 1980). Learned Visual C++ to build a check ordering system. BTW, I hate software! Finally got into the infrastructure side and did a bunch of data center relocations, DBMS upgrades, and general equipment upgrades. Designed two-way mid-split cable systems for most university campuses. Moved from engineering into project management in mid-'90s and worked up to VP PM. Retired in 2020. I do miss having a couple of hundred folks working on a large project team, but I don't miss the stress of managing budgets, timelines, personnel, vendors, and especially finance.
Hate to tell you this, but IBM introduced their PC in the fall of 1981...

But total respect for your software background - you date from the days of wooden computers and iron men! FORTRAN 66? That's back there aways - wasn't there a 72, or 77 or something? I only dabbled in FORTRAN - and COBOL.
 
Hate to tell you this, but IBM introduced their PC in the fall of 1981...

But total respect for your software background - you date from the days of wooden computers and iron men! FORTRAN 66? That's back there aways - wasn't there a 72, or 77 or something? I only dabbled in FORTRAN - and COBOL.
I know. We worked with ESD on the development. Cassette tape recorder was "mass" storage device. No hard drive option. Two 360kB, 8" floppy drives and BASIC burned into a ROM. What many people don't know is that the only reason the IBM brass allowed Estridge to make the PC was to use it as a replacement for the large, heavy, and expensive 327X monitors so as to sell more big iron. IIRC, the first run was 5,000 and sold out in two weeks.
In '83 (I think) they replaced the BASIC chip with a WordStar-like word processor and sold the PC and a daisy wheel printer as an alternative to their $10k dedicated wp.

Also worked with Wang (Dad, I shrunk the company) on their LAN, Wang-net that never went anywhere

Met with Bob Metcalf to explain why using a baseband cable system was not a good idea, but I think he never understood the difference between baseband and FDM.

Bought an Apple II to manage an environmental test stand, but it kept crashing. Finally got to an engineer at Apple who asked if we were using a lot of matrix math. Said, Yes, and he said it gets confused after a while and needs to take a rest. What a toy!
 
Bought an Apple II to manage an environmental test stand, but it kept crashing. Finally got to an engineer at Apple who asked if we were using a lot of matrix math. Said, Yes, and he said it gets confused after a while and needs to take a rest. What a toy!
A bug in the software, probably a stack imbalance would be my guess. All the early SBC computers were toys. The IBM PC was a complete disaster. Combined the the worst aspects of the model 1 TRS-80 and the Apple ][+, and the best of neither. It was ignored as the toy it was by the "serious" micro computer folks (read: S-100) of the day, as a result all the amateurs from the Apples, TRS-80s, PETs et al migrated to it first - and brought their bad programming and hardware habits with them. Which made a poorly designed system even worse - but it did bring one thing that no other microcomputer of its day had: The letters IBM. There was a lot of talk about IBM and Xerox "legitimatizing" the Microcomputer in the computer rags of the day (Byte, et al). Xerox's entry wasn't anything new, and has been lost in the sands of time. Then they gave the PC a DOS that combined the worst features of CP/M and TRS-DOS and the best features of neither.

40 years later, we're STILL stuck with the thing, although most of its shortcomings have either been phased out, or lost in the noise. Who cares today if there's a hole in the lowest 1 meg of RAM - but back in the day it was a real problem! It took a couple of decades for these amateurs to figure out that tin plated connectors were a bad idea - as proven by Radio Shack. But we're also still stuck with Intel - which was the worst decision made in Boca Raton, if they'd only gone with Motorola... At least we don't have to deal with crappy 5-1/4" floppy drives anymore - the PC was widely criticized for not using 8 inchers.
 
I work in IT for a University, but more on the hardware/infrastructure side. A lot of what I do involves problem solving and building solutions to fit what the colleges want to do. It can be stressful at times, but I do like going home at the end of the day knowing I fixed/improved something or made someone's job easier.
 
  • Like
Reactions: Zorba
Electrical Engineer here...Worked in IT and tech R&D for years, about to start new RF Engineering job. Seen some crazy shit in IT. Bizarre unexplainable stuff. Done a lot of assembly code, C and C++ of course. My latest personal project is taking on Boston Dynamics :) Fully 3-d Printed, 12 20KG servo motors.... Working on getting this boy moving. Maybe adding a LIDAR next
IMG_20211019_190909_644.jpg
IMG_20211019_190909_761.jpg
 
Last edited:
  • Like
Reactions: WestCoastDan
I write code for industrial and large commercial HVAC and refrigeration control. It's not the simple on/off function block diagram stuff with a few PIDs thrown in like the old days... It's actually a text language strongly resembling...oddly enough...Pascal. There's not really any web, security, or file handling involved, but I do enjoy the occasional algorithm challenge and the hardware isn't a PC so I have to mind my execution time and memory usage.
Scada?