Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 08/17/2019 in Posts

  1. 1 point
    Hi, On the 15 August we got a few complaints that customers get this run time error 5 when they are trying to download application via U90Ladder. We investigated more and found that this is an issue caused by the latest Microsoft update. In order to solve this issue until Microsoft will release new update - Please try to uninstall the update via "New installed updates" or roll back before the update. Please see below link to Microsoft update and known issues: https://support.microsoft.com/en-us/help/4512508/windows-10-update-kb4512508 *For other version of Windows Microsoft KB article number will be different. Article can be found in the below link: https://support.unitronics.com/index.php?/selfhelp/view-article/u90-ladder-and-runtime-error-5 Best Regards,
  2. 1 point
    Just for clarity to everyone following this saga. The EXL-CAB295 is for the EX-A2X, NOT the EX-A1!
  3. 1 point
    Hi all, some of you might have read my post here: http://forum.unitronics.com/topic/3992-unit-id-check-etc-on-online-test-first-login-on-a-bus-system/ I have been trying different approaches to this problem and have finally found one that makes it a bit easier. I have always had multiple instances of Visi set up for when I am writing code. If you don't know about this capability, read this entire post: http://forum.unitronics.com/topic/3884-question-about-visilogic-coding-operation/ to get the overall picture and pay attention to Shane's post at #4. For my multiple online monitoring I have had great success using many multiple instances of Visi, all with their own access address and program set for the plc I want to connect to on the same system. I leave all the instances open, overlapping enough to be a useful size but able to be clicked easily to bring that window into focus. I also run a remote access instance set to another sub-address on the unit that I just only need to observe. I have found this entire process to be invaluable when needing to skip quickly between various plcs on a connection. Instead of disconnecting, finding and loading the relevant program again, changing the unit id drop-down and then finally clicking connect, you simply disconnect in the currrent window, focus the relevant one, click connect and you're in. AND on the correct plc/program match without any stuffing around.....as long as you've got it right to start with! I have found this to be an absolute boon on working on a system that was previously a PITA to monitor and adjust due to all the linked plcs. The only caution is not to forget to disconnect on switchover, otherwise the network error comes up. But truly, it's a doddle compared to the previous way! Cheers, Aus
  4. 1 point
    Paul^2, This is a really good example of a complex EX-RC1 application so I'm going to crank through it for the benefit of the forum. Thank you for posting your code! CANbus is a "sending" protocol - you don't read the PT400 inputs from the V130, you send them from the EX-RC1. The same applies to digital inputs. It's also not the easiest thing in the world to understand, but once you've done one it makes sense. It's important that you map out your memory first, as described below: Laying things out- EX-RC ID #2- No DI modules IO-PT 4 modules not configured and mapped to local MIs - I configured them as DIN 100 RTDs and mapped them to local MI 11..26. Open up the hardware configuration on the RC1 to see what I did. So - RTD's located in MI 11..26 with be sent to ID #1 V130 MI 201..216. I chose this address block because there's nothing existing around it. Local O32 ..O95 - V130 outputs O8..O71 This will require four MIs to hold all these bits- V130 MI 20..23 -> RC1 #2 MI 40..43. I didn't use MI 20 in RC1 because it was already mapped to temperature data. EX-RC ID #4- (make sure it really is ID #4 based on the DIP switches) No DI modules IO-PT 4 modules partially configured - I configured them as DIN 100 RTDs (alpha = .0385) and mapped them to local MI 11..14. RTD's located in MI 11..26 with be sent to ID #1 V130 MI 221..224. Local O32 ..O63 - V130 outputs O72..O103 This will require two MIs to hold all these bits- V130 MI 26..27 -> RC1 #4 MI 110..111. IO-AO6 module - configured 0-10V to local MI 60..65. The V130 will send its own MI60..65 to these. This is a lot to get you head around, but take your time and make your own map of what registers and outputs in the V130 correspond to which I/O in the RC1s. All your actual control code will be written in the V130. And I may have made a mistake somewhere in here. I wasn't able to test the configuration. Let me know if it behaves. Joe T. 1 EX-RC3Paul14-7-2018 JT.vlp Main1Paul14-7-2018 JT.vlp 1 EX-RC2Paul14-7-2018 JT.vlp
  5. 1 point
    Hi, I attached here a simple and working example of sending SMS to multiple numbers using DT. Just make sure to: Change on net 5 the greater than block according to the number of phone numbers you wish to send to. Add the numbers to the DT and download it to the PLC via the 'write values to PLC' button from the Data tables top menu. sms multiple phone numbers with dt.ulpr
  6. 1 point
    And now for my next trick........I found that you can also do multiple instances of Remote Access. Very useful if that is all that is needed, rather than running the full blown program. And, drum roll, the double whammy is that if you have different models on the same network, it actually "shows" them, reducing confusion even more! My pic shows two over the top of writing this post. Cheers, Aus
×
×
  • Create New...