- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
If the timing is critical, why is it Python?
Admin
So that when the inevitable failure happens the evidence is concealed by a conveniently placed giant foot.
Admin
Because Python handles microsecond precision timing just fine, and in my experience, the hardware and communications medium is far slower than Python anyway.
Admin
TRWTF is the company. or python's GIL. idk
Admin
I grew up in a time when communicating with hardware mean reading signal charts. So, hard? No. Annoying? Yeah, maybe.
Admin
Timing can be critical, but also on relatively slow paces- on a lot of robotics systems, you might need to make sure something happens once in a given interval and that interval might be on the order of milliseconds. No big deal to hit that timing in your main loop- if nothing in the main loop pends for hundreds of milliseconds waiting for a timeout.
Admin
High-tech agriculture...
Imagine the Food of the Future, reaped with Super-Connected-Crypto-Metaverse-ChatGPT-Tractors.
Think about it. What could possibly go wrong?
Admin
To be fair, if I understand the article correctly this is massive agricultural machinery we are talking about. You know, stuff like tractors weighing several tons and towing all sorts of sharp and potentially moving tools. Or combine harvesters that slice and dice corn and wheat, process them further and eject shredded bits out a chimney. Stuff like that.
So what if we skip a signal? What's the worst that can happen?
I mean, worst come to worst these things will always be surrounded by squishy humans and maybe even animals milling about the sharp bits so they can notice things have gone wrong in time to scream about it.
Admin
@SoylentGreen:
Don't worry, nothing will go wrong, trust us.
Admin
I worked with a very smart person who had earlier worked (doing software) at a potato factory in Idaho. His comment: "you only have to dump five tons of potatoes on the factory floor once to get a lot more careful with your code."
Admin
I had a similar situation writing code for an industrial controller — in 1979. The device monitored a bunch of sensors, and periodically had to make a phone call to a modem and transmit a report. The “modem” in the device was a software modem; I had to switch a relay to dial the phone number (no touch tone generator in the device, just, pulse dialing) toggle a register to send the ones and series. Of course, the monitoring had to continue while the report was being transmitted, so the comms section of the software had to be non-blocking.
My manger asked why it was taking so long, ignored my explanation and whipped up a phone dialer/transmitter — in Forth. Now Forth has some nifty features, but using it would mean including the Forth runtime, his code, AND the sensor monitoring all in a SIXTEEN kilobyte PROM.
I ignored him and finished the non-blocking interrupt driven dialer/transmitter, we shipped it and went and installed it at the client site, and on that trip I learned NOT to match drink-for-drink with the marketing team.
Admin
Python isn't too bad as what matters in realtime code is that you keep servicing things like event loops regularly and that an event handler takes no longer than it should. How long that is depends on the particular setup. You don't use it where you have precise sub-microsecond constraints... but a lot of realtime code isn't like that.
I'd not be totally surprised if the typical time cycle in agricultural applications was on the order of a tenth of a second, and Python is usually plenty fast enough for that.
Admin
I checked the "microsecond precision", but the code shown in the example, supplied with minimal stubs to get it to run without errors, takes on average 1.9µs on a 2.6GHz i7. Getting Python to do anything meaningful in a microsecond is simply not possible, let alone write an application with microsecond precision timing in it.
Admin
Potatoes? Try automotive engines written in FORTH. Set the rpm to idle at what you think is 1000rpm and see it rattle through the gears to 10000rpm and you learn the difference between 1000 1000. and 1000.0