Ausman

MVP 2016
  • Content count

    335
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by Ausman

  1. Hi Ram, Please post your code if you can, MBs do not directly relate to time. Are you wanting to change the RTC, or change a timer's setting? cheers, Aus
  2. 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
  3. 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
  4. 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
  5. 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
  6. Are you doing a compile and save after the slight mods, before doing the download? If so, and without luck, perhaps a minor rename of the file will work as well. I have never encountered this issue, but I always do my first suggestion for the most minor changes. cheers, Aus
  7. 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
  8. 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
  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
  10. Does the screen come up if you get into info mode? I can't remember whether SB9 controls this or only when the program is displayed. cheers, Aus
  11. 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
  12. Hi all, I've whinged about this in the past, and it is still a major source of problems for newbies on the forum. Can we please have all the installation and program files tick the "Run as Administrator" flags themselves? I don't know the mechanism as to how this gets forced, (and quick searching didn't reveal it) but it can't be that hard. I encounter other programs where it is in place, so it just seems silly that Unitronics do not do it when it is absolutely necessary for the correct operation of their programs. It's a bit like getting a new car, then wondering why it doesn't run because it's something as fundamental as not having petrol (gas for you yankees!) in it. If it's needed, do it automatically. cheers, Aus
  13. 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
  14. 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
  15. I'd initially be splitting out your operations in 75 into smaller blocks. Let us know how that goes. cheers, Aus
  16. 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
  17. Hey Cara, do I get a prize for being the Lucky 1000th post on this forum? Ha Ha, Aus.
  18. Have you got a differential set up on the setpoint? Without this a change of +/- 1 might trip things incessantly. cheers, Aus
  19. Hi Adam, Have not done an LX350. However, I'd first be throwing things at the printer via your PC using any of the serial port software out there like Hercules, to check that it is indeed working as expected via the serial line connections you've done. And also to check that that command structure works as expected. Then check what the PLC is doing by monitoring it's outputs. Somewhere between these two operations you'll likely find the stumbling block and be able to correct things. If it has indeed worked in the past, I would initially be suspicious of your total wiring config to the printer. Extra connections needed onto odd pins is not uncommon, or perhaps it is something as simple as a 2 & 3 switch. You may even end up needing to use a breakout box to help figure things out. cheers, Aus.
  20. Monitor your Com ports in Device Manager during hookup. cheers, Aus
  21. Hi Visco and all, I'm not completely sure what you're trying to do here, Visco, as your input being an MI is a bit self-regulating for possible amounts. Doesn't my screenshot below do it easily? But if you put 1000 into MI0, your result here will be 1, without any dec point. So this raises my question of what exactly are you trying to do with the result? Is it simply maths, displaying etc? cheers, Aus
  22. Hi again, vehicles are notoriously noisy electrical environments, so I had always assumed that you were running a buck/boost with heavy filtration as the power supply, and protecting the PLC with shielding in an appropriate box. It would be an easy thing to also have this configured as a UPS, with it's own very small battery done appropriately into the main system so that it only connects once the engine is running and stable. As an aside, I once had a very stable computer system go absolutely haywire at the crucial 24 hour team relay circuit race I had built a dedicated laps monitoring program for. It worked fine during extensive testing, but once at the track, in the tower 15m from the nearest approach point, certain vehicles would play havoc with it. Ended up having to move it into an underground room much further away for the race duration...very annoying!! But we are talking an Amiga 500. Ahhh...how times change! cheers, Aus
  23. Hi Flex, Not really as good. Drum is much better due to the inbuilt timer system. The process needs the timeouts to forcibly progress if needed and sometimes these steps are not very long. If I was using a SM, I would still have trouble monitoring things easily. If I could actually have everything showing realtime in the drum configuration window it would be very useful. For example, in the linearisation config, you can directly monitor the values. I want much the same in the drum config. I can't see that it would be too hard to do. cheers, Aus
  24. Hi all, would it be possible to have live drum checking? I am working with a reasonably complex one. It is hard to keep up with the steps by referring to my screenshot of the drum layout and then cross-referencing it back to the only way of seeing where it is up to by looking at the index number. It would be much easier if I could have a means to "open" the drum configuration when on line, with it showing where it is up to and also the timer counts if used. Please, please, please! cheers, Aus
  25. Yes, but only after doing some trials on the innate accuracy of the method. Like I said, in theory it is accurate and will work ok, it's meant to be a precise 2.5 or 1.25. If it is ok through extended testing, you would set it up so that you can easily match it to the master and go from there. I'm wondering whether the error you currently get is due to the firmware not reading the RTC info every scan? Alex? Saragini? cheers, Aus