Jump to content

Ausman

MVP 2023
  • Posts

    2,702
  • Joined

  • Last visited

  • Days Won

    189

Posts posted by Ausman

  1. Hi all,

    I thought I'd share a little trick I've had for many years...in case I get hit by a bus.  Hate to see it wasted.

    Much of my stuff is machines that plug into normal General Purpose 10A outlets (Aus = 240V).  As such, years ago I had a lot of trouble with DC motor drives pulling way too much current when they were powered up, and they would routinely trip the breaker on that circuit.  A normal solution would be a different curve breaker, but in these locations this was not possible.  Most Inrush limiting devices are designed to be on the load's PCB, but back then there was little around for me to use anyway.  I had to come up with a bullet-proof but simple way of doing it.  As usual the brain got the washing machine going and out came this idea at the end of the cycle.

    I ended up with 2 variations of the theme on the attached pdf.

    1).  The pdf version uses a relay and normal light globe.  The globe reduces the inrush to minimal levels because initially it is running at it's "normal" conditions.  But there is enough voltage still getting through to the load that it charges up it's capacitors with hardly any higher current at all and the globe's brilliance decreases as this happens. It's essentially working as a simple resistor.  Once voltage at the load reaches the relay's trip threshold, the relay turns on and supplies full power until the main source is switched off.  You vary the globe's wattage to find the ideal compromise time, in most instances I work on 0.5 to 1 second.  You will be surprised how well it works if you do an experimental lashup.

    2).  In many cases I have multiple drives to power and I use the PLC to control the initial powerup.  They all go through a master safety contactor when running directly, with a further individual relay/contactor downstream for each.  In this case I initially run them sequentially through a link to a globe in the same manner.  ie the globe "neutral" is on the downstream side of the master contactor but before the individual switching.  The PLC runs them all through a sequential power up via the globe and then closes the main contactor once all the routines finish. Thus I have a single globe that glows brightly, dims, next drive turned on and globe brightens again, dims etc etc with all drives eventually being powered direct.  Once it is all finished, I then do the motor control necessary.

    I know that most of the time this is not necessary.  But I still encounter moments when this method has proven itself time and time again.  The beauty is the inherent simplicity and also the ease of replacing the restrictive mechanism...the globe.  Not that I have had to do it. I first implemented it over 20 years ago and on ALL devices it is still working on the same drives....and the same globe!  

    Globes must, of course, be nasty "environmentally unfriendly" old fashioned filament types.  Not modern, "full of mercury and electronics" flourescents, or "specific frequency hard on the eyes" LEDS, which are all sooooooo much better for the environment...ha!  But that's another discussion along the lines of a Prius vs a Hummer!

    cheers,

    Aus

     

    INRUSH LIMITER.pdf

    • Like 2
  2. Hi Nicola,

    Everything AlexUT says is relevant, but I would also like to know if this is the same plc in your Download error post?  And is it a different model to the others you refer to that work ok?  I would also make sure they are all the most up to date OS.

    Re the drivers, perhaps before going further with Alex's requests, have a good read of the post here, and the other link it refers to:

    Check everything out and if you still have issues, then do what Alex asks.

    cheers, Aus

  3. Hi Nikola,

    It's a long shot, but I'm assuming that you have installed the usb drivers by using the button at the bottom of the PC Communication Port Settings window?  Controller/M90 OPLC Settings.  If not, try this and see what happens and advise back for further suggestions. You might have a few drivers in your system messing things up.

    cheers,

    Aus

  4. Hi Saragini,

    I cannot send the projects as they are proprietary and am exploring the issue at present to find a definite cause.   I made a simple project to test things and it all worked fine.

    In the projects where the problem is evident, it seems to be related to items on HMI screens where addressing/referencing has been changed to a new location and the old one reused for another aspect.  But I have run out of time for now so will advise further when I can spend a bit more time on it and hopefully pin it down.

    cheers,

    Aus

  5. 11 hours ago, Flex727 said:

    since it's only removing the description

    Ahh....but Flex, check the next jpg out.

    To demonstrate, I deleted the description of MB0 and in doing so it also dropped the Use tick.    It now doesn't appear in the Operands not Referenced box, but it is still in use in the program.  You are right, there is a bug, I've never thought of complaining because I just resigned myself to never use it!

    Mostly I keep track of things, but occasionally during further mods I come across an element that doesn't make sense, then discover it isn't in use and was part of a previous method of doing something.  These are the elements I want to completely see in one overview that will help me clean things up.

    cheers,

    Aus

    Uni2.jpg

  6. HI Flex,

    I have always found Operands Not Referenced to bring up things that are actually used in the program, and therefore don't use it.  See attached pic. 

    But, right click on an operand in the list and do a Find "X" and it will correctly identify those that aren't used at all, but only one at a time.  I would like one click to find all of them.

    cheers,

    Aus

    Uni.jpg

  7. Hi all,

    In Visilogic I am requesting that in Edit/FindElements we get the ability to find all unused elements in one search.  In complex programs during development I can't be alone in losing track of things that have been tried, need modification and eventually turn into unused elements.  Although this "shouldn't" happen, in the real world it does.  Pencil work can only do so much!

    I wouldn't care if it took a little while to run through a simple loop covering everything it finds supposedly used within all the operand tables, as it would save vastly more time than going through thousands of elements manually!

    cheers,

    Aus

     

  8. Are you saying that it might not be the buffer, just a token clash due to a gradually coinciding trigger time? 

    In that case I will definitely try the "ping-pong" system, which is in line with your request timer suggestion.  I would set it up to easily vary the number of scans before the trigger activates/resets things, to trial different delay times. The system is running 500Kb at 0.5 sec, which I might vary a bit just for interest's sake as well.

    But it is curious that I am running controls that supposedly say everything is ok to do further operations,  which surely accounts for any sort of clash anyway.  I still had the Unican Sends in the ladder all working OK, just no remote access, so this pointed me to the buffer.

    Due to the crucial nature, the distance away and strict "do not ever touch this" rules for staff on site, I will only do the changes when there.  I've been caught once and I don't like driving 4 hours for 2 minutes work to rectify something I created!  I'll set it up for my next visit and will advise results.

    I repeat that the help file could have a bit more detail about various operations and real world limitations.

    cheers,

    Aus

  9. Thanks Joe,

    I essentially have things set up as the help files, with 3 Unican sends chained instead of the single element shown in the help .  I have attached scrnshots of a bit of my code that relates to this, and particular areas of the help file, notably the parts that stress not to directly do a send...use a trigger.  Ideally the triggers for my application are at most 1 second apart.  The one second trigger worked fine, lowering it to 100mS seemed to create the issue.  I have the sends in both the 130 and 120 set as low priority...haven't tried using high and it's associated SB.

    The problem with the job is the remote nature of it, I can't experiment too much in case things go so far astray as to prevent access or correct operation.  Upgrading is not possible at present...the usual "we have no $s" that you and I have whinged about!

    cheers,

    Aus

    3.jpg

    1.jpg

    2.jpg

  10. Although I don't have this problem through not having ACAD, to me this definitely looks like a file format/extension issue, or a shared driver, and this is upsetting things.

    I had such an issue with other programs years ago, and after heaps of messing around, the only solution was to make the computer dual boot.  Both boots were identical apart from the two conflicting programs, so I only had to change if the particular program was needed.  As all variable data was on another partition, this was an easy thing to do.  But backup all data and also do a full drive copy first in case of hiccouphs.

    I would also initally be going back to a restore point prior to the install, or if not possible, running a registry cleaner after doing the uninstall.

    This problem could also simply be Msoft updating something that previously worked fine b/n both programs, but now doesn't.  Mr Gates and crew sometimes have a lot to answer for.

    cheers,  Aus

     

  11. The key words here are "0-20mV transducer".  It will work fine if you run it through a conditioner that will give you a usable output.  A quick google brings up many examples.

    As Flex says, 0-20mV will not give you much resolution, if you get it to read at all.  But couple it to a conditioner and it will.  14 bit vs 10 bit may have given you a reading, but it wouldn't have been very useable, unless you're simply looking to see if O2 is there or not.

    cheers,

    Aus

    • Upvote 1
  12. If you installed SD Card Suite, then you easily have the ability to convert the UDT one way.  Open the UDT by double left click, and it opens using Data Tables Editor.  Under the Home tab at the top, in the second block from the left, is Export to Excel.  You then choose what you want and end up with an excel file.  Also note the CSV, and copy paste buttons next to it.  This export then lets you manipulate things in Excel.

    BUT........shifting info back from excel to a udt is harder.  Unless I have missed it, there is no function available to do this in one hit.  My method has been copy from within excel and paste in data tables editor, but this is SLOW for large blocks of data (you will think it has hung), and also sometimes throws up an error warning.  You have to check the numbers once the paste is finished.  It is awkward, sometimes needs more manual input, but works.

    Before you do any operations, only use copies of your original data table.  Sometimes during this process I have had a save occur, without notification.

    I would be very happy for someone to point me to a xls to udt converter on the Unitronics site!

    cheers,

    Aus

  13. Hi all,

    Something interesting and useful.

    Would like some suggestions on an observation.

    I have a V130 talking with a 120 via Unican, and over time with program improvements I have been adding more and more communicating of parameters both ways between the two via Unican sends.  I posted about this some time back and the answer was pretty much just send blocks concurrently as things will work.  This has all been working fine with my having a trigger for the operation in both units based on SB13 and 202.

    I have always been a little frustrated by the lag in response of the 120 when accessing remotely through the 130 via the LAN.  Recently I was onsite which is imperative for an "iffy" change in such a crucial system, so I decided to change the trigger to SB15 (instead of 13) in both units.  There was a definite improvement in remote access timing, and all the information needed was still being transferred correctly.  Left 3 hours later all still working OK.

    Next day logging in remotely I couldn't get into the 120 at all, not even to do an initialise and reset.  I ended up having to firstly change the 130 back to SB13 and then that let me get back into the 120 to also change it back, but with some timeout hiccouphs along the way.  A bit of nail biting as this was all being done remotely as the site is two hours away!

    So....I obviously had some sort of buffer issue that gradually built up over time to eventually make the bandwidth needed for access via Unican unworkable, but there was still enough for the Send/Receive components to still be working fine.  I don't know whether the inter-unit accessing "linkage" is also controlled by the Unican parameters I have set for the send blocks.....someone know?

    I have always thought my SB13 timer a clumsy method of control as the two PLCs might drift around to hitting it concurrently, but I have also been under the impression that although Unican didn't really mind this it still needed some sort of buffering.  My experience shows that some sort of buffer allowance is definitely needed, so I can't just use SB202 as the trigger.   It would seem that even if 202 says things are ok, there might be another few scans needed to really clear things.

    So what is the best solution here? 

    Is it to setup a count based system where the two units "ping-pong" off each other?  ie 130 does it's sends, and in doing that it sends one bit that is read and reset by the 120 which waits a few scans and then does the same thing back to the 130 ad nauseum etc etc?  The ideal number of scans would have to be ascertained by trial and error.  The problem I see with this is if something goes astray, because it relies on the link working perfectly each and every time, the entire link will fall over.  But I could cover this with a master "timeout" of say 10 seconds in each plc monitoring the bit changes.

    Or use some of the SIs to better control things?

    There is not a lot of help info about Unican capabilities, perhaps a bit more involved detail would be good.

    cheers,

    Aus

     

  14. Exactly, JohnR.

    Visco, remember my comment about sometimes things can be simple, sometimes complex.  A major part of programming is pinning down exactly what you need to achieve, and then finding the easiest way to do it.  I often put all my known methods into the washing machine called the brain, and ages later I still end up with something not even considered in the first place!  It is a constant learning curve.

    cheers,

    Aus

×
×
  • Create New...

Important Information

This site uses cookies. By clicking I accept, you agree to their use.