My first gigantic project - a review
fogled@mizzou
Posts: 549
Last summer I posted a message about tackling my first gigantic programming project. That project is largely behind me now, and I wanted to follow up with some observations.
A port for every device. I can't remember who posted this, but it's marvelous advice. Every device has it's own port on touchpanels. Every device can have it's own button index. Say goodbye to get_last! My only 'mistake' in the implementation was that the devices controlled by multiple touchpanels were using the highest port numbers. This could lead to memory issues. I've got a total of 5 panels; 1 that handles everything, and 4 more handling mostly ports 30-50, on a NI-4100. but... this thing purrs like a kitten - no memory problems here!
All code running on a single controller; the other 5 controllers are "empty" masters being driven by master to master communications. Having done this makes me realize I could replace all those other controllers with IP-Serial devices, save money, and have the same result. This design has yet to cause a single problem.
Almost all data tracked by the controller is handled and stored in structures. They're clean, simple, and they work. I'll never touch another multi-dimensional array in my AMX programming career.
Timelines - I gots dem! Lots of them. 30 of them run all the time; it's common to have 60-70 timelines running simultaneously. They just work. No drifting, no misses, no hiccups. WAIT, I hardly ever knew ya.
Buffers for non-panel devices, and buffer processing in Program, just works. Marvelously. I'm very pleased with the robustness and consistency of this approach. Data.Text, I never did know ya, and... I don't want to.
Sharp Aquos suck. The units communicate inconsistently, and we've had 6 failures in 6 months, out of a pool of 30 units. Can you say 40% annual failure rate? I thought so.
I still made some significant mistakes in the modularity / consistency of my programming. There were lots of changes and additions during installation, and there were a couple of instances where my code just wasn't written to accommodate that. But I learned.
Overall, I'm very happy with my part in the project. The users are happy with the panel designs, and an A/V system that spans 3 buildings and controls 50 devices "just works." The code base I developed for this project has already saved me a tremendous amount of time on my next project. Onward AMX soldier!
I never could have pulled this off without the collective wisdom of this forum. Thank you all for your time, expertise, and contributions!
A port for every device. I can't remember who posted this, but it's marvelous advice. Every device has it's own port on touchpanels. Every device can have it's own button index. Say goodbye to get_last! My only 'mistake' in the implementation was that the devices controlled by multiple touchpanels were using the highest port numbers. This could lead to memory issues. I've got a total of 5 panels; 1 that handles everything, and 4 more handling mostly ports 30-50, on a NI-4100. but... this thing purrs like a kitten - no memory problems here!
All code running on a single controller; the other 5 controllers are "empty" masters being driven by master to master communications. Having done this makes me realize I could replace all those other controllers with IP-Serial devices, save money, and have the same result. This design has yet to cause a single problem.
Almost all data tracked by the controller is handled and stored in structures. They're clean, simple, and they work. I'll never touch another multi-dimensional array in my AMX programming career.
Timelines - I gots dem! Lots of them. 30 of them run all the time; it's common to have 60-70 timelines running simultaneously. They just work. No drifting, no misses, no hiccups. WAIT, I hardly ever knew ya.
Buffers for non-panel devices, and buffer processing in Program, just works. Marvelously. I'm very pleased with the robustness and consistency of this approach. Data.Text, I never did know ya, and... I don't want to.
Sharp Aquos suck. The units communicate inconsistently, and we've had 6 failures in 6 months, out of a pool of 30 units. Can you say 40% annual failure rate? I thought so.
I still made some significant mistakes in the modularity / consistency of my programming. There were lots of changes and additions during installation, and there were a couple of instances where my code just wasn't written to accommodate that. But I learned.
Overall, I'm very happy with my part in the project. The users are happy with the panel designs, and an A/V system that spans 3 buildings and controls 50 devices "just works." The code base I developed for this project has already saved me a tremendous amount of time on my next project. Onward AMX soldier!
I never could have pulled this off without the collective wisdom of this forum. Thank you all for your time, expertise, and contributions!
0
Comments
--John
One of the challenges I have faced with large projects is having many UIs of different types, ie: wired and wireless 8400s, CV10/7s, 5200s, R4s, DMSs etc all in one project and expected to work similarly. This increases the difficulty factor as all these have different sized screens and absorb feedback at different rates, and have to be treated differently even though to the client they should seem identical.
A couple of things that puzzle me though:
1) Having all code on one master and using others as slaves leaves you a single point of failure. While it is easier to code, if that main master goes down, the entire system goes down. The multiple master jobs I have done have the code spread across them in a logical way so that if one goes down only a small subset of functionality is lost.
2) Structures cannot be passed to modules but arrays can, so I tend to prefer them to structures as my projects consist mainly of modules. There really is no advantage to using structures as opposed to arrays that I can see. Plus they use more memory if that is a consideration.
3) I don't use define_program at all and in a busy system this makes a huge difference to the snappiness of the system and feedback to the panels. For example, the Kaleidescape module uses a for loop in define_program for button feedback, and it is very slow in a busy system on a wireless network.
4) I agree about the Sharp TVs. Unfortunately customers like them anyway.
5) The modularity/design factor is the second most important thing to me. Most projects get updated, modified and changed so being able to change things quickly or add zones/sources/UIs quickly is paramount. To add a zone/source/UI to a project usually only involves adding it to an array and including a module if its a new source. I have it so that in a typical project I will have 20-30 modules and only 3-4 includes. I try and write the modules so that they work with multiple devices and UIs, so that only one module is instantiated no matter how many devices or UIs there are. This also cuts way down on memory usage.
There are an infinite amount of ways to do a large project and its different every time due to the constraints of the situation/client/budget etc. The compromises are what make it fun