My company wants me to get our new controls division up and running (it currently doesn't exist) using these new Spyder controls with the AX front end. The last controls I worked with was Tracer Summit back around 2007. I'm lost right now with Spyder even after 9 hours of training. Is it just this system, or are all of the current generations of controls (KMC, Alerton, Johnson, Siemens, etc.) this confusing and difficult? Just to get into programming the stupid thing I have to start this platform, log in, start this and that service, log in, connect this, start that, it's ridiculous! Why can't there be a batch file that starts up everything on my laptop and brings me to a simple login screen just like every other system I've ever worked on?
Originally Posted by jlaber
I guess what I'm looking for is the info I need to figure out if this is something I'm going to be able (and willing) to learn in a short time. If not, we either need to pursue a different system or I need to pursue a different company. I was a full-time controls tech for several years and got burned out on it. Now I primarily do Commercial HVAC/R service work and have been enjoying that. I told this company I didn't want to do full-time control work but I guess they didn't hear me. Supermarket Racks are what I really love, but we don't do that.
If your heart is not in it you are probably better not doing controls Spyder's is not the easiest controls to work with that for sure, but these days, depending on the type of buildings and system you are installing there is usually multiple devices to "integrate" that will require more than a single piece of software.
The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. - Bill Gates
You can create a batch file to start Workbench and the platform daemon for the version you are opening. You will still need to make a platform connection to start a station on your laptop and then the station connection. Not a big deal, takes about 15-30 sec depending on the size of your station. If you are connecting to a jace then you can just log right into the station once Workbench is opened.
Do you need a batch file for XP or Windows 7?
If you are not familiar with AX or Spyders then you are in for a big learning curve.
Originally Posted by klrogers
Originally Posted by klrogers
Well, like the controls world, this forum software has holes in it, so the long-winded post I just typed disappeared because the system decided to log me out and upon returning to the reply page it was all gone.
Short story is, it's not just Spyder. It's a lot of controls systems, if not all of them. Similar to the way that experieced DOS-based programmers/users suffer from over-complicated and bloated GUIs that are perceived as superior by those who don't want to take the time to learn how to use faster, more efficient software of the old days, control systems are following suit. Concepts such as object-oriented languages and graphical programming could very well be designed as well as the older software so that it works just as fast and reliably, but the trend I am seeing (based on prior product development experience) is that manufacturers no longer build upon the wisdom that, once upon a time, was valued and passed down to the younger generations. The result is inexperienced product developers, and with no oversight from well-seasoned old-timers, the doors are wide open for ignorance and arrogance to prevail. My analogy is: why don't chemists develop something better than water? Maybe because enough people understand the merits of water, not to mention absolute dependence upon it. However, far fewer people understand the merits of simpler, faster, more efficient software, so every newbie who enters the software engineering market today has the notion that they will be the next Einstein, and with inexperience comes the notion that "I have a better idea, and it can't be compromised by some old fart slowing down my progress, so let's throw out all the old concepts and re-invent the wheel from the ground-up".
Another factor is the nature of contracting and DDC sales. We are usually not selling to the people who use the systems, and certainly not the programmers. We are selling to executives who write the checks, so top priority in product development is to create new features that look good on a salesman's quote. As a programmer, your job is to just make it work regardless of whether the process keeps getting harder, more over-complicated, and slower, while the customer is under the impression that the opposite is true.
No need to remind me to get out of the DDC field-programming business, that's already in the works. Once upon a time I developed computer-based musical instruments and recording equipment. From that world comes some very strict marketing rules. Any musician or recording engineer would laugh hysterically if they hit a note on a keyboard or turned a knob and had to wait 100 milliseconds, let alone seconds or minutes, to hear a response. Don't bother telling me that DDC is far more complicated until you've designed a keyboard to be able to respond to 10 notes simultaneously with limited hardware resources, without any perceptible delay, plus creates sounds that musicians want. Also don't bother thinking that the slightest hole or inconvenience in the user interface wouldn't cause the community to criticize the product hysterically, instantly dropping sales to zero. Most software engineers who intern for companies that build brilliantly-designed, fast-reacting musical instruments simply move on to other jobs where none of this matters. It's an incredible amount of hard work, and involves a lot of old-fashioned techniques like assembler-based code, FPGAs, RISC processing and real-world testing, testing testing and re-testing. They didn't go to college for their jobs to be hard. But on the other hand, the employers value their programmers a lot more than a general contractor will appreciate the frustrations that a DDC programmer will experience, so the working conditions are far, far, far more favorable.
I've learned that to survive this industry, you need to take your heart OUT of it, and just become numb to all of the BS that you will be swimming in all day every day. It's far more about chugging along, making it work, and not caring whether you have any opportunity to become good at what you do, or whether you find any sense of gratification in it. There will never be gratification to be had for a DDC programmer. The harder you work at providing a quality product, the more time it takes, and the more you will be spit in the face and thrown under the bus. And don't bother complaining, lest you will be deemed a lazy, candy-a** p***y who has never swung a hammer or sweat in his life. And yes, I've swung hammers, and rebuilt engines, and replaced 50-year old AHU shafts on 50 HP blowers, so take my opinion for what you feel it's worth. Sure I cussed, got injured and dirty, but at the end of the day at least you could say the job was done, done done. It was easy to see it was done, and there was rarely a request to go back and re-do the work because the customer's whim dictates that they didn't like the way it was designed to work.
So, despite my extreme frustrations due to the above mentioned circumstances of our industry, there are good things to mention about Spyder. The graphical programming model is decent, and when there's a problem, the debug mode will lead you right to it. The Niagara-based environment will back up you entire project with a single command. The Spyder will indicate when something is left in manual override, and has facility to cancel overrides via a single command. To avoid the pitfalls that led me to post earlier in great frustration, I recommend that you license a PC or Windows-based niagara box to temporarily install on site if you want to do remote Spyder programming. An embedded JACE (like a JACE-6 for example) will work, but at some point, resources are likely to run short, and you may end up chasing your tail because all kinds of weird stuff could happen, or if you're lucky, it will just crash and reboot itself and you'll lose your work. If you can reduce frustrations on that front, at least you'll have more room to deal with real-world problems like your controller power being switched on and off all day, space sensors disappearing, balancers scheduled to start while you're still in the middle of programming, and the plethora of baloney that the construction industry has to offer. GCs don't care whether you need to have steady power, and that your field devices need to stay installed, and that all devices must be on line before attempting to commission/bind a Lonworks network (at least in Niagara). All I've ever heard is "not my problem". You need to get it working, doesn't matter whether it's physically possible. You can't explain something to someone who refuses to understand. So, as long as there is no heart, no pain will be felt. Just go do the work, and most definitely don't take the situations you're faced with to heart. Or if you're smart, build your business strictly on design-build projects for retrofit jobs that you've sold directly to the building owner. In that case you'll be in much better control of the circumstances, and won't have GCs, construction schedules and liquidated damages looming while you run into unexpected technical setbacks.
Thanks for all the insights, jlaber! I think it will be years before we get to the point where I'm doing programming all day. A steep learning curve doesn't excite me at all. We're a residential HVAC contractor with a commercial department. I'm a commercial tech, but spend most of my time working on splits and RTUs, which is getting old fast. It's even harder to work on that all day and then switch over to learning a new career, essentially. The Spyder on the AX platform has almost no resemblance to anything I've worked with in the past.
I could quit today and go work for a union mechanical contractor as a service tech with awesome benefits, doing boilers, chillers, etc. It seems like an easy choice, but I don't want to let my current employer down.
Yes, it doesn't seem to matter what level of involvement one has with controls programming. Based on the comments from most others in the industry - PMs, sales, operations managers, business owners, commissioning agents, balancers, site superintendents, even carpenters, bricklayers and laborers - it's become very very clear to me that the programmer is the one stuck with the greatest levels of frustration. It would be great if either the products were designed so that the work flow is extremely efficient, or all the above people the programmer depends on have their jobs done well in advance of the scheduled completion date. After more than 10 years in the field things are still getting worse. There are more devices added, like CO2 sensors and airflow stations, and the sequences are becoming more complicated, not to mention less sensible, the products more complicated and slower to program, schedules getting tighter, customer expectations greater, plus exponential increases in tech support calls, you name it, if it make the field programmer's job harder and more frustrating, it will happen. Did I mention all the different incomatible versions of software, the dependence upon third party software that keeps changing and breaking existing installations, such as Java updates? Or integration into packaged units like boilers, chillers and AHUs with factory-supplied controls that communicate via standardized protocols. It sounds like a great idea, but the reality is that packaged controls run a fixed sequence, yet the DDC programmer is tasked with making them fit a custom sequence, so we're stuck with making it work half-way by programmatically manipulating setpoints and overrides. By far, it is a lot more sensible to specify a blan-slate mechanical system and control it 100% via DDC. However, the very purpose of Lon and BACnet is for every manufacturer to be able to get their little piece of controls into the sales quote.
Originally Posted by man from trane
I don't want to let my employer down either. He's great to work for. It's the situations we get into and the nature of the contracting business we are faced with in the field that brings me closer to just turning my back on it all so I can go back to a modest-paying office job where I can take vacation time like everyone else does, in the summer because that's when my wife is off (teacher), and be treated with maybe a tiny little bit of respect. So if anyone would like to make 6 figures doing what I do, sooner or later there I will be leaving an opening.
Looking at the cost of living in MA I suspect the garbage men would have to make 6 figures. Here in Omaha that's a nice income! I don't know, I still haven't made up my mind whether to accept this challenge or go union and avoid the stress, make the same money with incredible benefits. I would have almost no health ins. costs, full pension paid for, free tools, guaranteed annual raises...or none of the above. But in the union I may be faced with weeks of boring grunt work. Cleaning boilers, punching chiller tubes, washing out cooling towers, who knows? Actually, that doesn't sound too bad compared to being holed up in a mech room sitting on a 5 gallon bucket with my laptop, wondering why my program doesn't work or the points won't pass!