Jump to content

kvlada

Members
  • Posts

    49
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by kvlada

  1. 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.

  2. On 2/28/2024 at 12:37 AM, Gabriel Franco said:

    Have you considered using a weight transmitter instead? It has been a cost-effective solution to me

    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.

  3. 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.

    outputs.png.654e45a1ee66c77c7f13b48620ffabfc.pnginputs.png.dc87ebf0edf8d0d1ebacde4bc88b0d9c.png

    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!

  4. 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?

  5. I like to use subroutines in two ways:

    1. 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, .....
    2. 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!

    • Upvote 2
  6. 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.)

  7. On 3/29/2024 at 1:11 AM, kratmel said:

    You yourself answered the question about the reasons for the failure of ethernet modules. In any case, the user should read about the permissible working conditions before using the equipment in the field. Accordingly, you have a choice - to take one communication module or another.

    It is another matter to replace the entire controller with the program if it is fundamentally impossible to replace the communication module.

    Of course, there are no perfect things - there are things that fit and not quite. On the forum there were examples of systems where the PLC was simply installed on a vertical DIN rail. - This is another simple solution to the port pollution problem.

    I met a PLC hidden in an IP67 cabinet made of stainless steel, which was hidden in another IP67 cabinet made of stainless steel, which was installed in the IP67 body of a machine that packed sausages. To the question of why the controller failed, I answered - it overheated. The plastic on the controller crumbled from the temperature, but the machine worked for some time (about 4 years).

    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.

    • Thanks 1
  8. 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?

  9. 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?

  10. 22 hours ago, kratmel said:

    Duct tape is probably the cheapest solution.

    And in fact, in several modern Siemens 1200 series, I already replaced the ethernet controller chip due to a short circuit that completely blocked the operation of the PLC. I don't know the reasons.

    I did not encounter any problems with the ethernet controller in the Unitronics PLC.

    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. :)

  11. 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.

  12. 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...

  13. 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.

    • Like 1
  14. Hi!

    One TCP client can connect to only one host at the same time. In program function "TCP_IP" you're calling TCP Client Connect function twice for two different IP addresses on a single client. This cannot work.

    You can try one of the following:

    1. Create two TCP Clients, give them some random but different address in configuration. Later when connecting, call function as usual but on two different clients. I'm not sure if this will work, but it's worth trying.

    1.png.9f2ce4e0335a23eb97a7e42d836baa03.png

    2.png.50147ebbf19a0a8a90616ae2097f2da6.png

     

    2. Use only one TCP client, but switch IP addresses. For example: connect to first printer, when connected do data transfer, then disconnect, and connect to second printer, do data communication, disconnect, and so on.

    3. Switch to UDP instead of TCP. Communication over UDP socket is similar to serial port, there is no connecting and disconnecting.

     

    Also: I've noticed you have put TCP Client Rx function but not Parse Message function, which would parse the received bytes in the buffer into a message defined in Message Composer. Parse Message function should be triggered on "Data Arrived" bit.

     

    Hope this helps!

  15. Unitronics  published a software update for Vision PLCs, which requires you to set an alphanumeric password to access PLC via PCOM protocol for online and programming mode.

    When upgraded, only those with the password will be able to access the PLC and download new program. Password can be set via ladder, or via HMI, so operators in field can change passwords on their own per company policy.

×
×
  • Create New...