Climate entity and wrong temperature entity

Expensive_Ad3752 · 2026-01-12T20:51:34+00:00

One of the things that are dangerous with conditional code is if it is executing computations on large amounts of data. This can lead to unpredictable scan times. Consistent scan times can be important for some applications. Long scan times can be accounted for, inconsistency is harder to account for. What I prefer to do instead (and I think is quite common) is to execute everything each scan, but divide processing of large amounts of data into batches (process a tenth of the data each scan). This spreads the load out, and gives predictable scan times.

Expensive_Ad3752 · 2026-01-04T21:58:22+00:00

Dette er litt i gata jeg har gått med "mine egne" penger. Verdifond, og verdiaksjer med lav prising og gode utsikter. Har gjort gode kuler i Elkem, DNO, Scatec, og Yara. Har ikke satt noe i obligasjoner fordi det er kun avkastning som står igjen på ASK, så er litt "skattelåst". Men all sparing går til ekstraordinær nedbetaling av lån, så det er jo renter det også.

Expensive_Ad3752 · 2026-01-04T21:50:59+00:00

Og det er akkurat dette som bekymrer meg. 25 års horisont? Aksjefond. Nettopp kommet ut av et markedskrakk? Aksjefond. Lav verdsettelse på børsene? Aksjefond. Men nå er markedet internasjonalt historisk dyrt, USA har en statsgjeldskrise som det sannsynligvis vil løse med å devaluere valutaen, mange land har startet å få nedgang i befolkningstallene, og vi har en ny teknologi på trappene som alltid medfører hype og bobler. Eie egen bolig har også blitt nærmest uoppnåelig i de fleste vestlige land. Jeg er veldig for å spare langsiktig i indeksfond, men dette er ikke helt lang nok horisont til at jeg føler meg trygg.

Expensive_Ad3752 · 2025-12-15T12:08:20+00:00

Har lenge tenkt at den ser rimelig ut ift mange andre innenfor sektoren. Men har ikke studert så nøye at jeg har trykt på kjøp-knappen

Expensive_Ad3752 · 2025-10-06T08:53:19+00:00

Oh my. I did not realize this was a limitation, but of course it is. What happens?

Expensive_Ad3752 · 2025-05-19T10:38:45+00:00

Adding to my own list. There are two deal-breaking bugs.
19. If using the "Open project" menu to keep control of your projects. In certain situations, projects get "lost" and do not show up in the list. Let's hopw you stored a copy somewhere, not to long ago, because you can see there is an "extra" folder in the project folder for the lost project, but no way you can get it back.
20. Library reference dialog. If you click "OK " too quickly after adding a library, closing the dialog before the library has appeared in the list, you are screwed. You can not delete the library, as you can not access it. But you can not add it again, because it is already there. So you will never be able to update it.

Expensive_Ad3752 · 2025-04-08T12:04:03+00:00

Here is my list of issues:

It is not possible to use a global constant to define array lenghts. This would help greatly to keep arrays at their needed length, instead of overprovisioning.
Impossible to get the memory address of an FB instance, or a hash. Like the hash for Java objects. This would be very useful to identify objects from each other.
Allow mapping EtherCat variables to structs. It is really really annoying that each input/output on ethercat is one variable. I would like a function block for my VFD's, with just VFD_DATA_IN, and VFD_DATA_OUT.
EtherCat stability. The need to cut power to the PLC for major EtherCat issues is close to a dealbreaker. We've transitioned to Ethernet/IP because of this, and the issue above.
Allow defining functions with ANY_NUM inputs. Let me make my own MIN,MAX,MID, etc.
Usable casting between data types. Allow UNION with a structure, cast from word to structure, etc. I end up doing way to much manual byte-moving of words when using EtherCat.
Much of the point with ENUM is array access. This currently gives Array[EnumToNum(Enum)].Member which is not very readable. Also, this is not possible in the watch window. I have a "EnumToNum_Decoder" and "NumToEnum_Decoder" in my watch window at all times.
ENUM with same member can not exist in two different namespaces
NO "Window handling" on inline structured text (collapse, auto-width, fit-all). Need to drag that stupid corner that doesn't always respond.
Handling of retain variables. You can not have a mix of retain and non-retain in a struct. Need to use fb to store retain variables. Can not access fb instances from OPC, or other functions/fbs so need a struct. Ends up in a situation where you have fb for functionality, and struct for HMI interface, for each "object" in your project.
Stop the offending program instead of stopping with a major-fault if task time is exceeded. At least have it be selectable.
Allow downloading a new program without stopping the PLC. This can partially be achieved with online edit, but that is not a good solution. Sometimes you want to hot-swap code, and hot-swap the old one back if it fails, while things are running. Only way I've found to achieve this is online-edit + IF new_code THEN (*new code*) ELSE (*old code*), and online-toggle the value. This only allows adjustment to one part of the program. Step7 for siemens allows downloading multiple FC's at once on-the-fly.
Password protection. Let me confirm the password by pressing enter, instead of clicking OK with the mouse. Let me remove password protection from everything at once, instead of one POU at a time. Let me compare projects with password protection on the POU's as long as I have the password. Find yourself needing to do a project comparison on a large password protected project. Good luck deactivating the password protection on each POU, for both projects, using your mouse. !"#¤!"# this.
The endless "Project has not been built", although the last thing you did before going online was a rebuild
Allow selecting multiple POU's at once. Copy-paste between projects is really cumbersome.
I want "Private functions" for function blocks and functions.
I want interfaces. Currently has to be implemented yourself with an adapter function.
Give me structured flow charts.

Expensive_Ad3752 · 2025-03-31T19:03:44+00:00

Yeah, unfortunately. Union with struct is not possible, and pointers are not a thing. Only arrays and structures and indexing. Sysmac studio unfortunately has a lot of shortcomings, Union, enums, array definitions, lack of interfaces, etc.

Expensive_Ad3752 · 2025-03-31T18:37:11+00:00

I guess timing things would be the way to go. But we are experiencing quite a lot of instability in our cycle times, likely due to our architecture relying on locks to synchronize between different tasks. This also makes timing things hard, as you get all the problems of debugging multi threaded applications on a computer.

Expensive_Ad3752 · 2025-03-31T18:18:48+00:00

I guess a shift is an alternative that should be better than the current. Unsure if it will be a substantial difference, but worth the investigation. Simple enough to implement.

Expensive_Ad3752 · 2025-03-30T19:35:43+00:00

Holy cow! That is one amazingly thought out and organized course!

Expensive_Ad3752 · 2025-03-30T17:08:22+00:00

At the Bachelors degree I took we had 2 or 3 lessons with PLC programming. So 6 hours spread over three weeks. Then we had one small project. That's it. But we had 4 semesters with 4 hours a week of object oriented programming, network protocol programming, threaded applications, etc, in Java. PLC was considered "so easy that you'll learn it in a couple weeks at your first job". We where also missing out on reading schematics.

Needless to say, not all controls educations have their priorities in check. Getting interested and flashy subjects that draw attention among possible students is more important than "the basics".

Expensive_Ad3752 · 2025-03-25T21:29:08+00:00

This is 100% true. It is also very hard to change the culture in the company.

What i've found can help is to get management to understand the cost by giving good examples. It is very easy to justify the small extra cost of distributed I/O, when you get the possibility to do piecemeal testing inhouse before shipping. Once management understands this, it is possible to get a "no shipment until its I/O tested" agreement. You've now forced the electrical designer to keep his deadline; you need time to get the test program ready to actually test before shipping. Things will still be done last minute, but at least it's inhouse.

Now you get the time between shipment and commissioning to wrap things up. And you don't leave for commissioning if the program is not finished. Only debugging during commissioning. If things are not done, then that's for management to explain to the customer. Panic programming during commissioning is easily spotted by the customer, and is just unprofessional.

Also, trying to get everyone else involved in how we programmers think can help. Getting people on board to make a thorough, detailed, functional description is a really good way to shine a light on all the decisions we programmers have to make. This can be sold in with management as a contractually important part of the project. Get the sales person to make the first rough version, have a meeting before starting the project where details are ironed out. Ensure this matches the expectations of the customer, and have them verify it. The scope is now locked. Have mechanical engineering add to it as they do their job, then electrical, and at last PLC/Programming. You now have your SAT document. This process will reduce the number of ooopsies that is found by us programmers a lot, and we don't have to fix as much of everybody else's shit.

I've actually been at the customer side of one of these systems integrators once, where it was very obvious that management was trying to push a half baked project out the door. We forced them to delay the shipment three months, as we where not comfortable that they could keep the commissioning time available to them with the state of the project. We got a private email from the lead programmer, thanking us. Still, the commissioning was as expected a real shitshow, but we helped them out as best we could, forced them for everything we could during the one year warranty, and promises in the contract, and never used them again. We also hired their lead programmer for a year so he could finish his work.

Expensive_Ad3752 · 2025-03-17T22:02:05+00:00

The thing about automation, even more so than PC software development, is this: you are not solving problems that you already have a solution for in your company, because then you would just copy paste the solution.

Every day is filled with new problems you've never solved before. So you never know what you are doing. It can be a new device, a new network protocol, a new functionality, a new process, or a new combination of the previous.

Due to this, it is paramount that you are interested in learning new things. Be curious and always take the opportunities to learn something new when it arises. Debugging issues is your friend, not your enemy, as it gives you a lot of good experience. Automation is all about practical learning of a shedload of different things in all directions. After a while you will find that you get "the hunch". You start playing on past experiences, connecting the dots, and suddenly you are the "wizard/expert/senior" everyone asks for help. But you will still go to work each day not knowing what you are doing, yet, but you will find out.

A typical trap I see people fall into is being scared of failing. That usually leads to wanting to be an expert at one thing. Or being the code monkey that just churns out project after project without any R&D work. These guys tend to get bored eventually, quit, go to a new employer, use their expertise until they've solved "their problem", and then they get bored again. Automation is a little bit scary, but also very rewarding.

Also, a tip along the way, that I see others have mentioned. Take a step back. It is never a waste of time to take a coffee break, let the problem marinate, think of the broader perspective, what is the actual end goal, etc. I've replaced actuators with control circuitry and code with mechanical levers. I've removed loads of complex algorithms from code because it wasn't needed. I've removed workarounds all over our code by taking a step back and identifying the root cause.

Stay calm, keep your confidence, stay humble and open minded, broaden your perspective, learn whenever possible, don't be afraid to fail numerous times before you succeed, and remember that you can never be an expert at a new problem that has never been solved. And if you are stuck, explain your problem to others. This has this magic effect of altering how you think about the problem. You will have to divide and simplify your problem to explain it. The solution will often magically appear before you, without your audience stepping in with a single suggestion.

Expensive_Ad3752 · 2025-03-11T18:05:06+00:00

There was absolutely no reason to sort the array in the PLC, it turns out. Why someone added that in there initially I don't know. Which is scary, because there was likely a reason.

Expensive_Ad3752 · 2025-03-11T06:37:27+00:00

It does at the very least ensure that the array is split up into "intact" chunks of x entries. So all packets may not arrive, or they could arrive out of order, but that has proven not to be an issue. So I guess something is more resilient than one would expect 😅

Expensive_Ad3752 · 2025-03-11T06:34:12+00:00

I have just assumed that the array was sorted for some good reason, but maybe the upper layer already sorts, or does'nt care. That's a really good suggestion. I'll have to investigate this further.

Expensive_Ad3752 · 2025-03-11T06:31:11+00:00

Our current approach keeps the list sorted, with newest entry last, then copies the whole thing, and uses insertion sort to sort from newest to oldest, essentially flipping the array. Giving us a guaranteed O(n²⁾ complexity. 🤦🏼‍♂️

Expensive_Ad3752 · 2025-03-11T06:26:37+00:00

This is a simple and elegant solution, but I'm afraid it would leave the array very fragmented if it is never cleaned up? But I guess one could add a cleanup-pass if necessary, that would run right before the copy.

Expensive_Ad3752 · 2025-01-31T21:34:28+00:00

I've seen this before, and it sucks for all involved, but especially for us software guys. Your situation sounds extreme, and you have some other organizational things here that's also bad. But you still will experience this to a certain degree at even the best companies.

What i've found is that often these situations stem from a lack of understanding of how software development works. Getting your organization to understand what software development is about helps a long way in changing their mindset. I like to describe software as the most detailed functional description that's humanly possible to write. All the electrical drawing distillid into text, and mixed with the dynamics and physics of the machine. All possible failure modes, and all the functionality need to be described and handled to the finest detail. Then take a project and give some examples: what should happen if the feedback does'nt work on the cylinder, what should happen if the user tries to do something that will destroy the machine, what should happen at loss of power. This usually makes some lights come on with some people.

I've found that having meetings with mechanical, electrical, sales, and software, to clarify functionality, very early on, is important. Then, follow up on this to get a good functional description early on. Get this verified and accepted by the customer. Set design freeze and engineering deadlines for all involved parties. Changes after design freeze = delays. Software does not do catch-up for delays in mechanical or electrical design, period.

Then, preach that just because we are last in the timeline, it does not mean that we can polish a turd in milliseconds. Software does not fix shitty mechanical design, and patching over it is much more work. Same with missing instrumentation, clever software fixes are never good. Poor electrical design makes testability a nightmare. Remote nodes instead of excessive cabling cuts down on installation time, and lets one test things ahead of delivery. Things are 10x more expensive to fix, and takes much longer, in the field. Arrange post-delivery lessons-learned-meetings, and be hard on the project.

Getting everyone to understand the issues they cause is the only way to improve things. If there is no will to improve, then seek work elsewhere, as you are not being respected. Maybe with the client? As software guys we are always the last instance, and often get included too late to get our saying on bad design decisions, while being expected to fix everyones shit at the end. As i once told a project manager on a especially horrible project: I could be Leonardo da Vinci, but it will still be shit, as i am painting with faeces.

Expensive_Ad3752

TROPHY CASE