kvlada

The function works alright. I've also made my own function with creates a full timestamp string using two calls to RTC to ASCII v2.

Okay, I'll give it a try. Thanks for the find!

Yeah, but that's a custom function and seems like an overkill. Vision had a built-in "Numeric to Bytes" function which worked fine. There must be something similar in Unilogic.

I can't for the love of me found how to convert a RTC date into a string, to keep it in a data table or a struct. Timestamping! How is it possible in UniLogic? Can I somehow pack the RTC into a string like "26/Sep/2014" and store that string or RTC Struct in a data table? Or is there some special kind of struct I can use for this?

I like to use subroutines in two ways: PROGRAMS. Split the ladder program in manageable and easily navigable sections. So instead of having one single ladder program with 1000+ rungs, we have a program tree in which we can easily find, add, remove, or debug functions. Example in C language would be creating different units like: main.c, inputs.c, outputs.c, hmi.c, hmi_extras.c, ..... FUNCTIONS. Make program functions which can be called multiple times. Example in C language would be having a library, like: io.h, printf.h, strcat.h, ..... When using subroutines like PROGRAMS, you must call functions only once, and without any condition. That way you've made your program easy to read, and you can be sure that all ladder code is always executed during scan. No "dead code". When using subroutines like FUNCTIONS, you can call the functions per condition as your program demands. Similar to C or ST functions. These functions subroutines should be marked differently or be placed in a separate program module. Examples of such subroutines might be: a function which creates a real-time string from RTC system registers a function which resets all specific process bits to zero a function which checks if a data table contains valid data a function which converts an array of bits into a register etc, etc., Hope this helps!

ON TIMER is the simplest form of PLC timers. It has a coil and a contact. When the coil is powered** the timer starts counting time. When coil loses power, it stops counting and resets elapsed time to zero. Contact closes when the coil is powered AND the elapsed time > preset time. Timers do not halt program execution. The program just tests the status of coil, and updates the contact. (** by "powered" I mean it has positive/true program logic on its input or left side. If this was a physical timer, then it would mean it has voltage on A1/A2 wire terminals.)

The modules which failed on me were located in V1040 and V130 PLCs, mounted in large 20" x 20" panels which had proper ventilation. The V1040 also had a temperature monitor alarm which triggered when Controller Temperature (SI 14) went above 50 degrees. The alarm was never triggered, and controller reported to be in 40-45 celsius range. It could be that these were just defective. Nobody is perfect, not even Siemens or B&R. When I checked the PLC, I've found that only the network card was overheating, not the rest of the PLC. Maybe there was an overvoltage or EM transient coming from the network cable. I've installed hundreds of these cards and without any problem whatsoever. The V700 which has integrated Ethernet port never had any issues also, and I've installed at least 50 of them at various sites.

Okay, thanks @Joe Tauser, that sounds like a sensible solution. I noticed option "IO Configs" in Uni-I/O configuration, but it's sad it only refers to add-on modules, not to primary controller configuration. Would be great if it could be somehow updated to work with controller variants.

Ah yes, that's it. Thank you @Saragani! ❤️ Why I couldn't do it, is that I forgot the "Properties Window" on the right, I have to select proper data type in there. Otherwise it won't work! Now I have additional question: can I have multiple struct types as inputs to a for-each loop? Because I've defined one struct for "current" data which isn't retained, and other one with different settings data which *is* retained. For example: Run, Feedback, RPM, CurrentLoad... are stored in a non-retained struct, and data like WorkingHours, OnDelayTime, IsMonitored, ... are stored in retained struct. I've done this to save memory space, because max space for retained vars is less than non-retained. If this isn't possible then,... I might have to merge these two structs into one which is wholly retained. Or are there any other workarounds? Can I have structs within structs? Or an array of structs?

Is it possible to execute ForEach loop on a list of structs? What I'm looking to do: For every motor element I have a "run" struct (run, feedback, hours counter, wye-delta soft timers...) and a "settings" struct (power-up time, setting bits, preset times, etc). This way I have a neat "motor object" for every motor, without having to take care of 100s of individual bits and integers everywhere. Instead of manually calling a function for each motor, I'd like to have it somehow automated. I made a list of "run" structs and "setting" structs for each motor. Number of list elements of run and setting structs is the same. But when I create a ForEach loop, I can't choose any of the lists I made. Only way I can feed a list into a ForEach loop is if that list consists of primitive data types, that is: bits, integers, reals, etc. Not structs! Is this possible in any way?

Interesting... I've had a few V100-17-ET2 and V200-19-ET2 fail in the field, due to overheating. Might explain why there's V100-S-ET2 as a "wide temperature" model. Unistream, no problems so far. First installation 8 years ago and counting.

A problem which did not exist with Vision series, but exists in UniStream PLC: - You want to test some new PLC code. - In the field, there is USC-B5-T42 PLC installed and working. - But you have a USC-B5-B1 to test out your code (for example). There is no simulator in UniLogic. Only way to test your code is to load it into a real PLC. But problem is that UniLogic doesn't allow you to download a user app if PLC model is different. For example downloading a T42 into a B1 version of PLC and vice versa. It means you basically must have each type of USC PLC on stock to verify certain application modifications, or to do it on-site. Alternatively you just forget about having onboard I/Os on the PLC, and only go with B1 variants. A solution to this could be as easy as putting a checkbox in UniLogic settings, to report I/O mismatch as warnings, not compilation errors.

Because even in the cleanest of panels, dust still somehow settles on components. And if the Ethernet port is exposed on the top side, it's bound to catch it. Add a few unattended years of service, and that RJ-45 port is seriously filled with things you don't want to be in. Siemens solved this problem by putting Ethernet ports on the lower side of PLCs. Even Vision PLCs have a side mounted jack. But not USCs. Guess I'll be shopping for some rubber plugs...

Check your Unitronics front panel for a small opening on the lower side. That's the speaker grill. It has a sponge dust isolation, but maybe the caustic materials are somehow seeping in through that hole. Might be worth sealing that hole (if you don't need sound) and trying if the problem persists.

Main question you have to think about is: how fast do you need these discrete I/O to be? If you can tolerate 50-100 milisecond latency, then taking a Modbus TCP or Modbus RTU I/O gateways might be a less expensive alternative to Ethernet/IP. UniStream can be easily configured to send outputs and read inputs from a Modbus field I/O station. Setting up fieldbus in Unistream is almost trivial, no coding is necessary. Just define tags, set polling time or trigger bits, and it works auto-magically. Now, if your I/Os must be fast (response time in 5-10 milisecond range) or real-time, then you should look for CANopen fieldbus I/O.