3 ms·

Did you ever have the pleasure of working with Siemens' SCL? I found it very frustrating to use but overall a better experience than just using the lego blocks

Did you ever have the pleasure of working with Siemens' SCL? I found it very frustrating to use but overall a better experience than just using the lego blocks programming you usually see. Combined with your data blocks you could at least get some structure into your programs.

WillReplyfFood 9y ago
I did, i did and i used the TC synonym. The problem is- as with all state-charts fast grows in complexity to a level where nobody has a overview. Are we the first industry to encounter this. No- chip designers have this all the time, game industry has this all the time, every fucking industry using state-charts has this - all the time. So how comes, we are the only industry taking a lot of overtime all the time? <chirpin ciccadas since decadas> I have people whos VMs literally collapse under page-long state-charts. So how about breaking them up, just have small state-charts in FBs and small state charts in FBs marshalling them. Not happening. And they use assembler, not for a final tweak but as base language. And usually, when the whole mess is collapsing in on itself, like a black hole of bad design, the project manager call in some external consultants, who should be happy to work a project that is "that far along -its allmost done". A castle made from dinosaur bollocks.
- rukenshia 9y ago
  I think the big problem in us being that slow is that you can't properly test changes. The initial programs get written under immense time pressure to put it productive and what after that? Do you want to touch your productive system and refactor it and risk causing hundreds of thousands in damages for production loss? You pretty much need to nail your initial design and can't afford to do the usual "we will take care of our technical debt later". I hear you saying "but you have debuggers/simulators!", for anyone actually having worked in the field you will know they are pretty much useless for big changes in machines that speak to hundreds of other systems, sensors, motors, etc. At least that's what my experience was and nobody has a backup factory to test changes on. In the tight schedules we had during production stops (Sunday nights, mainly) we were busy enough maintaining everything else than having fun on a PLC. I completely agree that this is all a big mess and people don't tend to write maintainable programs, they just want their machines running and this is where everyone needs to be trained and improve.
  - WillReplyfFood 9y ago
    The problem with testing changes is indeed that the environment at programming start is usually under construction and in itteration. Which is why a automatic proofer going over the state chart testing for edge cases would be great. Unittests against a simulation would allready be great if they would not test the whole process, but the working of components. Actuators and Sensors usually do not change that much- so basic test-coverage would be fine. Regarding the time, i found out there usually is time- a miserable long time at the project-end, where everyone crunches besides the allready deployed machine, personal loosing the overview of the architecture and thus leaving. We had programs where even base functionality had uncovered edge cases which would destroy parts of the machine. To detec these edge cases is absoluty doable with software or with decent planning. There is no real thinking about the life-cycle of fbs-during machine initalisation, start, stop and maintainenance. Instead something "working" is produced and then simply applied to a machine. Even companies who have some standards, meaning some internal guy who trys to keep software coherent and reusable, usually have a decay in architecture during the project. Statemachines, squished into one page long boolean statements and pages upon pages of copy paste code. Eletricians and mechanics coding with funny building blocks. This has to go.
  - jononor 9y ago
    Manual simulators don't give much benefit, manual testing in simulation is only marginally better than manual test on hardware. Need automated tests in simulation, preferably based on data collected in real systems. Ideally also hardware in the loop testing.
- golergka 9y ago
  > So how comes, we are the only industry taking a lot of overtime all the time? Have you never met a game developer?
  - christophilus 9y ago
    Don't know why the downvotes. I was once asked to work on the original Gears of War. After talking to the developers at Microsoft game studios, I noped on out of there. Most game devs I've met have horror stories of death marches followed by massive layoffs. It's... not a great sector of the tech industry, if you value work-life balance.
    - daemin 9y ago
      I would hope that the cycle of crunch -> ship -> layoffs is in the past now. From memory it used to be that way because the studio needed to crunch to get the product out the door to sell. Then once that happened they had no need for all of the people since there wasn't another product to work on. These days there are a lot of studios working on so called perpetual games (MMORPG, etc) which have constant maintenance and improvements so they don't need to let go of people. Also the other AAA game companies are bigger and can shift people between projects as needed.

WillReplyfFood 9y ago

I did, i did and i used the TC synonym. The problem is- as with all state-charts fast grows in complexity to a level where nobody has a overview. Are we the first industry to encounter this. No- chip designers have this all the time, game industry has this all the time, every fucking industry using state-charts has this - all the time. So how comes, we are the only industry taking a lot of overtime all the time? <chirpin ciccadas since decadas> I have people whos VMs literally collapse under page-long state-charts. So how about breaking them up, just have small state-charts in FBs and small state charts in FBs marshalling them. Not happening. And they use assembler, not for a final tweak but as base language. And usually, when the whole mess is collapsing in on itself, like a black hole of bad design, the project manager call in some external consultants, who should be happy to work a project that is "that far along -its allmost done". A castle made from dinosaur bollocks.

rukenshia 9y ago
I think the big problem in us being that slow is that you can't properly test changes. The initial programs get written under immense time pressure to put it productive and what after that? Do you want to touch your productive system and refactor it and risk causing hundreds of thousands in damages for production loss? You pretty much need to nail your initial design and can't afford to do the usual "we will take care of our technical debt later". I hear you saying "but you have debuggers/simulators!", for anyone actually having worked in the field you will know they are pretty much useless for big changes in machines that speak to hundreds of other systems, sensors, motors, etc. At least that's what my experience was and nobody has a backup factory to test changes on. In the tight schedules we had during production stops (Sunday nights, mainly) we were busy enough maintaining everything else than having fun on a PLC. I completely agree that this is all a big mess and people don't tend to write maintainable programs, they just want their machines running and this is where everyone needs to be trained and improve.
- WillReplyfFood 9y ago
  The problem with testing changes is indeed that the environment at programming start is usually under construction and in itteration. Which is why a automatic proofer going over the state chart testing for edge cases would be great. Unittests against a simulation would allready be great if they would not test the whole process, but the working of components. Actuators and Sensors usually do not change that much- so basic test-coverage would be fine. Regarding the time, i found out there usually is time- a miserable long time at the project-end, where everyone crunches besides the allready deployed machine, personal loosing the overview of the architecture and thus leaving. We had programs where even base functionality had uncovered edge cases which would destroy parts of the machine. To detec these edge cases is absoluty doable with software or with decent planning. There is no real thinking about the life-cycle of fbs-during machine initalisation, start, stop and maintainenance. Instead something "working" is produced and then simply applied to a machine. Even companies who have some standards, meaning some internal guy who trys to keep software coherent and reusable, usually have a decay in architecture during the project. Statemachines, squished into one page long boolean statements and pages upon pages of copy paste code. Eletricians and mechanics coding with funny building blocks. This has to go.
- jononor 9y ago
  Manual simulators don't give much benefit, manual testing in simulation is only marginally better than manual test on hardware. Need automated tests in simulation, preferably based on data collected in real systems. Ideally also hardware in the loop testing.
golergka 9y ago
> So how comes, we are the only industry taking a lot of overtime all the time? Have you never met a game developer?
- christophilus 9y ago
  Don't know why the downvotes. I was once asked to work on the original Gears of War. After talking to the developers at Microsoft game studios, I noped on out of there. Most game devs I've met have horror stories of death marches followed by massive layoffs. It's... not a great sector of the tech industry, if you value work-life balance.
  - daemin 9y ago
    I would hope that the cycle of crunch -> ship -> layoffs is in the past now. From memory it used to be that way because the studio needed to crunch to get the product out the door to sell. Then once that happened they had no need for all of the people since there wasn't another product to work on. These days there are a lot of studios working on so called perpetual games (MMORPG, etc) which have constant maintenance and improvements so they don't need to let go of people. Also the other AAA game companies are bigger and can shift people between projects as needed.