I wonder why they chose Palm, but then why not, and what else would they use? Ipaq?
It's not clear, but I assume it sends commands to the actual film hardware, and its not doing some real-time control.
"The software shows a handful of controls for the projectionist to queue up the film and control the platters that feed film at six feet per second. " [0]
Palm was the market leader, it would have been the obvious choice. Palm had been around since 1996 and by 1998 had sold 30 million devices [1]. PocketPC didn’t come out until 2000, in 2001 they had only sold 1.25 million devices, equating to less than 10% market share [2]. From what I remember Palm Pilots were the go to choice for PDAs, they were simple and worked. Other devices had come and gone. It would have been odd if they chosen something else. I doubt anyone was thinking it would be used for 20 years, though I don’t think people would have thought it would go away at the time.
I was thinking it’s not actually an obvious choice for controlling hardware. It was either an interesting choice that was small and didn’t need a lot of components, compared to the obvious PLC. Or it seemed like an obvious choice to someone that didn’t know better.[1] Either way, someone probably made a good decision to keep the old system maintainable by emulating the palm pilot instead of replacing it.
Mind you, it’s not clear how much of the control is done by the palm pilot. For all I know, it’s not much more than a screen connected to a PLC. But my gut feeling is it’s actually doing at least some of the control to be worth emulating and keeping the original software.
[1]You see this a ton now, with people reinventing the wheel using arduino, raspberry pi and spark fun parts to automate something in the small business they are employed at. Because they know these things as hobbyists, but they and anyone around were never exposed to PLCs. Soon after they leave, a newer employee will rebuild from scratch, maybe using ESP32. Overall the lifetime cost is probably much higher. Meanwhile a PLC from 1990 is fairly easy to maintain, repair or replace (including porting the software).
The costs could be as you say. And a arduino may last 25 years but a cheap power adapter janky wiring soldered to a hobbyist proximity switch will not.
I was thinking more of a scenario where a young engineer at least knows what a PLC is and buys $1k of stuff from automation direct. And starting from a PLC/googling about PLCs will lead you down a path of PLC cabinets, high quality power supplies, labeled wires and industrial limit switches. Vs another engineer that only knows the world of arduino and messes of wires in boxes.
In the first case, when he or she leaves and the thing breaks down, the next person can either call or pro or have a chance to connect to the PLC, do some troubleshooting with the ladder logic and figure out which sensor needs to be replaced. In the second case there’s probably no documentation and the source code is long gone so the only thing to do is scrap it and start over, probably incurring a large cost because now it’s an emergency to get the thing working again, and/or it causes lost production. I failed to mention earlier I wasn’t just talking about the cost of parts.
I’m not saying the imax solution may be so bad in the “arduino direction”, but thinking about it for me thinking about some professional experiences I’ve seen in both directions.
In my experience, hacked together arduino projects easily exceed a 25 year MTBF (if you exclude day-1 failures because someone did something stupid like wiring it backwards).
However, ESP32's do not (they seem to require a power cycle every few months - and in my view, that is a failure). R Pi's certainly do not (they require human attention for software updates, which IMO is also a failure - and even if you don't update them, there is almost certainly some tiny memory leak and it'll need a reboot in a year or two anyway).
That device specifically was cheap and readily available. If it failed you could have gone to any OfficeMax or Circuit City and picked up a replacement.
I assume at least one engineer aggressively argued for DB9 serial along with a Windows and Mac app instead and lost.
It was clear that the longevity of the installations would far outstrip the longevity of the Palm pilot
If I was in the room I'd even argue for DOS. As a target it had stopped moving, was ubiquitous, not going anywhere and is in enough important places that it would even survive the demise of Microsoft if they were to collapse in the future
"Yes, there's plenty of Windows CE and DOS palmtops. You can make a palmpilot application if you want but that should be a port, just like to BeOS.
The pure serial binary option is fine but this is infrastructure. Like the bridges that run on 5 1/4" disks, this will outlive both us and Palm if we do it right. Hell, if this is still running when our grandchildren are old and grey, this will be one of our greatest achievements as a team.
When I walk down the street and I see a masonry stamp on the sidewalk from a contracting company that installed it 100 years ago, I appreciate the fine work they did that I'm still using a century later.
Let's hope people will feel the same way about what we decide to do in this room today.
We need to at least provide documentation on the protocol.
It has to be made so competent people in the future can easily make this system accessible to the computers of the future as well. That will Not best be handled by a binary blob on a palmpilot"
Saying it should have been Windows CE is just survivorship bias IMO - and we don’t know that they didn’t write documentation on the protocol or that it’s poorly understood - it might just have been easier and safer to emulate an app that everyone is happy with rather than rewrite it (these film projectors might be more in “keep them alive” mode rather than “improve” mode while digital is growing for them).
I’ve put a dos application running in an emulator on an android device for a project to roll out new hardware because that took a few hours to configure rather than a year of development.
Did you you ever attempt programming anything under PalmOs back then? It was quite fragile because of the extremely low amount of memory on board, which forced the use of relocatable memory handles, a bit like classic mac OS.
PalmOS and it's extreme focus on low end hardware was a super weird choice at the time. The one reason for using PalmOS was extreme battery life, which obviously was not a factor here.
There existed plenty better alternatives at the time.
I think it's a bit unfair to say "for aesthetic reasons".
The article says it's because projectionists are familiar with the Palm Pilot UI (because to them it's just another tool), and rather than get them to re-learn a different UI, they used emulation to provide the same familiar UI on newer hardware.
We (technology/digital experts) take for granted our level of comfort in sussing out how a new UI works.
I don't say it lightly. It's trivial to remove the process entirely. The whole point of this style of projection is that it's as much theatre as the theatre itself. It's kept, including the aesthetic of the Pilot device itself, purely for nostalgic decoration and little more!
I think this is basically similar to the tension between if it ain’t broke don’t fix it, and the desire to improve (or if you like, recreate, iterate, etc) what exists.
They definitely did. My brother was happy to get my ibm branded palm pilot (WorkPad) because it would interface with serial obd-ii dongles. And the ice rink where my kiddo plays hockey has a scoreboard that was sold with a palm pilot to control it (someone in the beer league built replacement software for a PC when palm pilots became hard to source)
thats exactly why. It was a simple serial connection that could connect directly with other simple embedded systems. My local Lowes home store had a palm pilot that controlled their security system, and it was still in use just pre-COVID for exactly the same reason.
iPAQ ran Windows Mobile (a derivative of windows CE). I believe custom drivers were not well supported.
As well, back around 2009 I looked into Windows CE for a hobby project I thought about commercializing, and the licensing costs were INSANE. IIRC, there was a revenue component too.
While I don’t recall all specifics, I believe using Windows Mobile in an industrial use case it violated the EULA and you’d need to use a proper Windows CE env.
Total total guess here, but I wonder if they were tied to Windows CE, still paying licensing costs, given how few “true” imax screens there are, if the base licensing costs they’d have locked into 20 years ago, would’ve made “true” imax screens unprofitable/ have retired them at the onset of the pandemic
Idunno, Microsoft jumped through hoops to get folks ported to Windows Mobile. The problem was that WinCE was just vastly... more. At some point it essentially just looked like Windows. App development was quite straightforward. Mobile, on the other hand, was powerful but complex. And Mobile also had a really high bar for certification.
We definitely used Mobile in industrial use cases but WinCE was much, much easier to certify and much cheaper to keep around on old SKUs and LTS contracts.
It's not clear, but I assume it sends commands to the actual film hardware, and its not doing some real-time control.
"The software shows a handful of controls for the projectionist to queue up the film and control the platters that feed film at six feet per second. " [0]
[0] https://www.extremetech.com/mobile/imax-using-20-year-old-pa...