kvlada

It would be great to have a logic function which gives you a number of ones or zeroes in a register or array of bits. It's super useful when you want to check for condition if only one bit is on at a time. Good for checking some input conditions. For example: 0001011 (0x17) would output 3 (as there are 3 ones). Bit array "0000000000000001000000" would output just 1 because there's just one logical true bit. Sure, it could be done via software, but a dedicated function for that would be a time saver.

For me the most cost effective solution was using a simple and cheap serial weight transmitter, which handles readout and calibration (easy for maintenance crew), and has a serial output. If there are just a few transmitters, I hook them up to Modbus RTU. If there's like 20+ of them, I connect a simple Serial-to-Ethernet converter to each transmitter, which sends UDP packets to the PLC. This way I'm not limited to one specific transmitter type, I can use whatever is available. Even Arduino modules can be crafted to send data over serial port. Because UDP traffic isn't bound by socket limitation, it practically doesn't matter how many transmitters there are in the network. When PLC receives a packet, I just check from which IP address it came, identify the transmitter, and copy the data to a proper memory array.

Report from the field: testing PLC is USC-B5-T24, production is T42. I've made two array writes, one for inputs, and one for outputs. They are reading and writing to and from buffered I/O to real I/Os. It works on the Production PLC. I can just replace Controller Model and it works. The on-board I/O on the Testing PLC (with less inputs and outputs) does not work, though. But that's fine because testing PLC works by simulating I/Os in software anyway. Interestingly enough, deleting the blocks is not necessary. UniLogic doesn't even report a warning. Probably because both PLCs have on-board I/O. Hope it helps others!

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.