I have not seen Tesla software spec but I would like to see it. Do you have it?Have you ever seen a Tesla spec, the go I great detail for their software spec and how they want it done.
I have not seen Tesla software spec but I would like to see it. Do you have it?Have you ever seen a Tesla spec, the go I great detail for their software spec and how they want it done.
Just wanted to get some thoughts on dealing with co-workers who go off script.
We are a large manufacturing facility with multiple/ similar machines and most of the logic can be duplicated (standardized). My co-worker (equal) feels that each new task he is a assigned is an opportunity to reinvent the wheel so to speak, attempting to utilize rogue "logic-vomit" rather than what we have in place everywhere else.
One technique he is using lately (while vigorously talking to himself out loud) is to add a "_CS" at the end of EVERY single controller tag (RSLogix5000). So we now have 100s, sometimes 1000's of these "_CS" tags mixed in with controller tags that do not have "_CS" indicator at the end.
i.e.
Autn_CS
Autff_CS
Start_CS
Stop_CS
Red_Light_CS
Amber_Light_CS
Green_LIght_CS
The purpose - he wants to identify what tags are controller tags in the logic, without having to hover over the tag to see it's properties.
Other things:
- refuses to create an array in size that is anything less than 500.
- insists that there is an NEQ before EVERY single MOV instruction. i.e. if N7:0 does not equal N7:1, then move N7:0 into N7:1.
- HMI screens - lets go with the smallest font possible, and not organize or line anything up.
Seems crazy to me, unfortunately the managers here know absolutely nothing about programming, so I kinda have to live with it.
What would you do if your co-worker went off script and your boss(es) just didn't care?
Any other examples of logic-vomit like this that makes you lose sleep at night?
I have not seen Tesla software spec but I would like to see it. Do you have it?
Nope, I stand by that statement. Seriously, MOST of them that I worked with rarely showed up at the designated time to meetings or whatever. This would not have been tolerated if others did it but supervision would just shrug and say “well, that’s just how Joe is.”
The above may not be your experience but it has been mine with MOST programmers. It’s just them being unreliable and uncontrollable for “normal” job functions.
That seems logical, but your previous post it I got idea that it is something available to public.I don’t think that is something I should share.
It lays out all the tag structure, AOI’s, routine structure, etc. they even go as far to provide an hmi template with their standard layout on it.
Are they needed for these designated meetings? Generally, mechanical engineers love meetings. Also, some project managers I've been with want a daily meeting. It's a waste of time and you just hear why they couldn't do whatever the day before. Butts in seats meetings is old school and not productive for me.
I've verily rarely heard a programmer say they can't do a job because they can't program it. Then again, a good programmer should have the project done and simulated/tested before install.
I worked for several system integrators. I’m more referring to showing up at a designated time to begin a startup or checkout. A typical scenario was we were supposed to meet several maintenance people to try something out and invariably the programmer would be 20-30 minutes late which would screw up the whole day.
Another typical thing was/is many programmers would show up to perform a startup or field task and not have an extension cord for their computer, a table or stand to work off of, and expect others to totally accommodate them as if here comes Moses parting the sea. Sorry, but it got old after awhile.
Ok that was a bad example, because a Scale component should be in an AOI anyways. I don't use UDTs very much except for things like messages, records, recipes etc. Though I am contemplating using them more for poor-man's polymorphism since 5000 doesn't support interfaces or inheritance like Codesys does.If you created six tags like that for scale weight components I would shoot you. Create one tag of a UDT with each element. I loathe opening up a controller tag db and seeing 1000s of tags like this. Organize them into components.
Now, not picking on you, but just demonstrating that one person's convention is another person's pet peeve. So to the OP, nothing that programmers doing is really an issue.
CS - anything that helps identify a tags purpose is fine
NEQ move saves scan time
500 array is better than needing an extra element later which can't be expanded online.
HMI - yeah if not using alignment tools, shoot the *******.
Even if you work with very unique machines, I'm sure there is tons of things these programs have in common.I may be a knuckle dragger in this regard but I usually stick to using all controller tags for simplicity and maintainability by controls techs. Our processes don't lend themselves to multiple near-identical programs where tag names might be duplicated, though.
But I may be missing some of the advantages if program parameters. Would you mind sharing your thoughts on those?
But back to the original post- OP, you have my sincere condolences. That is an extremely frustrating situation.
I once worked with a PLC programmer that told me "I don't like abstraction, it's too complicated" I just stared at him. Like I can't even come up with a good analogy to explain how stupid that statement is.
CS - anything that helps identify a tags purpose is fine
NEQ move saves scan time
500 array is better than needing an extra element later which can't be expanded online.
HMI - yeah if not using alignment tools, shoot the *******.
Just wanted to get some thoughts on dealing with co-workers who go off script.
We are a large manufacturing facility with multiple/ similar machines and most of the logic can be duplicated (standardized). My co-worker (equal) feels that each new task he is a assigned is an opportunity to reinvent the wheel so to speak, attempting to utilize rogue "logic-vomit" rather than what we have in place everywhere else.
One technique he is using lately (while vigorously talking to himself out loud) is to add a "_CS" at the end of EVERY single controller tag (RSLogix5000). So we now have 100s, sometimes 1000's of these "_CS" tags mixed in with controller tags that do not have "_CS" indicator at the end.
i.e.
Autn_CS
Autff_CS
Start_CS
Stop_CS
Red_Light_CS
Amber_Light_CS
Green_LIght_CS
The purpose - he wants to identify what tags are controller tags in the logic, without having to hover over the tag to see it's properties.
Other things:
- refuses to create an array in size that is anything less than 500.
- insists that there is an NEQ before EVERY single MOV instruction. i.e. if N7:0 does not equal N7:1, then move N7:0 into N7:1.
- HMI screens - lets go with the smallest font possible, and not organize or line anything up.
Seems crazy to me, unfortunately the managers here know absolutely nothing about programming, so I kinda have to live with it.
What would you do if your co-worker went off script and your boss(es) just didn't care?
Any other examples of logic-vomit like this that makes you lose sleep at night?