Jump to content

Tips and Tricks


  1. Best Programming Practices

    Tips from Unitronics gurus

  2. Tips and Tricks

    This is where you can post items of interest that are not covered by other forum sections.

  • Member Statistics

    Total Members
    Most Online
    Newest Member

  • Topics

  • Who's Online (See full list)

  • Posts

    • I've got a few 130s and none have had a failure.  But perhaps there is another element in play here.  Nearly all the time my cards are not doing any actual "work" apart from maintaining, or trying to maintain, the connection.  The only use is a daily login to check a few things, and other slightly longer times when there will be a program update etc.  Vastly different to an installation that might be running the cards non-stop with large constant chatter between systems.  So the question is whether the amount  of card usage might heat things up too much?  That is something I don't know and can't answer.  Logically a device constantly doing "work" must generate more heat than if doing little, but perhaps not. And a side note on "duct" tape.  I've mentioned this before but a repeat.  "Duct" tape in Aus refers to a wider tape that is similar material to insulation tape.  Invariably this stuff slightly retracts over time and leaves a horrible sticky residue on removal, especially when subjected to any heat elevation.  If you are cutting squares of it to put over holes, it will likely not stay in place that well.  The better thing to use is what we call "Gaffer" tape which is also known as Race tape and perhaps other names around the globe.  It is cloth based and is much better for permanency in situations like this.   The other alternatives for covering openings, which I've had to do sometimes after removing a card and not having a replacement "breakout" piece, are: 1).  use a small cable tie to hold an external cover in place, with the tie run through dedicated holes or existing slots nearby.  2). tiny silicone dabs which are large enough to hold the cover piece, but small enough to enable ease of removal if needed.  Over the years I've actually found that this is the best of the lot, but "needs must" applies at the time! cheers, Aus
    • 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.
    • I'm a Non-Unilogic user, but I agree with Joe that it sounds like a retry length issue, which can be a problem if not correctly set up to allow for the time errors take to run out of attempts on the current request before trying another.  Are you sure that retries and numbers of them are being allowed for, or better yet for testing purposes, there are none?  Perhaps there is a setting squirreled away somewhere that you have forgotten?  Or don't know about?  We all learn something new each day!  😉 Question for my learning...is this 485 or TCP? I don't know the table source due to not having Unilogic.   If  TCP, could the plc be dropping the ethernet connection for some reason, and it's not actually a modbus issue at all?  If 485, bump the timeout UP a bit and see what happens. And also, is this involving the device that does addressing in hex?  Just curious..... cheers, Aus  
  • Blog Entries

  • Create New...