kvlada
-
Posts
59 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Gallery
Events
Blogs
Downloads
Articles
Media Demo
Posts posted by kvlada
-
-
19 hours ago, Ausman said:
Don't get me wrong, but I'm curious as to why? If the system is working ok, then isn't it simply "busy work"?
Reason is that VisiLogic doesn't allow you to download a ladder application if the PLC OS is not the same as one in VisiLogic. What happens when I have to make some changes to an app which was made with an older version of VL?
Of course, I could have many virtual machines with different VisiLogic / UniLogic versions, or use Version Swapper, but these are just complicated band-aids. Sometimes you need the new versions for new features, and they might even be mandatory due to security issues (introducing PCOM Passwords for example).
I've never encountered an issue that old program doesn't work with a newer firmware, and I've done OS upgrades of some apps that I've made in 2008-2009 time. That's why I believe Unitronics will be consistent in never breaking things in the future, as opposed to IT where "move fast and break things" is the norm.
Another reason is that I never know when the factory process is able to completely halt due to PLC being in stop mode. Sometimes the process or a machine can't stop for days. So, I like to keep downtimes at minimum, and upgrade as soon as possible. Once the OS is newest, I can later download a new ladder app without hitting a brick wall of having to shutdown everything for half an hour or so.
I understand your concerns... I just like to keep things simple and tidy, and not worry about OS.
-
I've always updated Unitronics PLCs to newest firmware (both U90, Vision and UniStream) as soon as it's released.
Never had any problems.
But always take precautions:
1. Make sure you have the correct ladder program (user app). Upgrading OS might sometimes wipe the user app, so you must download it again after the OS update is over.
2. Before doing anything, make a backup of the PLC memory (retained tags) and data tables.
3. If you have access UniApps (a.k.a. Info Mode on Vision), go there and make a complete backup of program & retained memory to SD card.
4. If PLC doesn't have an SD card, buy a 16 - 32GB card and load it into the PLC. They're pretty cheap nowadays. Perform the upgrade by telling Unilogic to save the new OS files to SD card (that's how I do it), instead to your memory stick. That way you don't need to worry about faulty or unsupported USB flash drives connected to the USB port. And next time you upgrade the OS, you don't even need to open the panel, because the SD card is already there.
5. For compatibility, your USB flash or SD card must be formatted to FAT32, and not larger than 32GB. Otherwise UniStream might not be able to recognize it.
6. OS update will take anywhere from 10 to 30 minutes, mostly depending on the speed of your media. I've found that SD cards are somewhat faster than USB sticks. Make sure you're allowed to halt the PLC for this duration of time.
-
Before copying files to USB drive, make sure the drive is formatted to FAT32. Newer partition styles like ExFat or NTFS are not readable by UniStream.
Windows Formatter doesn't have FAT32 option by default.
I've used Rufus tool in the past, and it allows me to format a drive using FAT32.
-
On 4/22/2024 at 1:00 AM, Gabriel Franco said:
I designed this Custom Control to control reversible motor. It has motor name, modes (O, P, M) , fwd start, rev start, alarm messages, alarm reset, interlocks status, motor status, close button.
This is a very interesting idea!
Can I ask you: how much is adding these extra controls and on/off visibility introducting lag into UniStream screens? Have you ever reached a point where a screen becomes unresponsive due to large number of elements?
-
17 hours ago, Chris Edwards said:
Can somebody give me a rough idea of what a UniStream 7" PLC+HMI cost?
You have three hardware variants with Unitronics UniStream product line:
1. Classical approach: UniStream variant where PLC is a completely separate device from the HMI touch panel, and it does not require a Unitronics-branded panel to operate. Most PLC equipment manufacturers like Allen-Bradley, Siemens, B&R or Beckhoff make PLCs like this, that's why I call it the "classical approach". For visualization, you can connect any VNC-capable device to the PLC and it'll show the screen, because the screens are rendered and processed inside the PLC, not on the HMI. Example: USC-B10-TA30, which is a flagship Unitronics PLC. It costs around $900 here in Serbia. A low-end PLC would be for example USC-B5-T24, going for about $500. You can hook it up to any HMI panel of your choice (VNC or raw fieldbus), or make visualization on a desktop PC, laptop, or a Android tablet. I would of course prefer a Unitronics HMI panel, and you can go for a USL-070-B05, which is a 7" resistive touch screen going for about $450 here. In total it would get to around $950.
2. Modular PLC and HMI: this is the original UniStream solution where the panel is executing and rendering the HMI graphics, while a dedicated CPU module attached to the HMI is taking care of program scan and communications. In this variant you must go for a Unitronics HMI and CPU module. Backside of modular panel has a plastic DIN rain onto which you can attach the CPU and additional modules, even your own components like 24V PSU or relays. Good thing about this variant is that you can add as many additional I/O modules that you need, and the bad thing is that the CPU module doesn't have any I/O onboard, so you must shop for I/O modules: digital and analog inputs, outputs, even serial ports. For this variant I'd go for USP-070-B10 panel (7" - $800) and USC-P-B10 (Panel CPU - $350), in total around $1150. You can add and I/O modules you need depending on the project.
3. Built-in PLC/HMI: this is the newest UniStream variant, which is similar to Modular approach, only the CPU and I/Os are integrated into the HMI panel. So instead of shopping for panel, CPU, and I/O modules, you get one device which has everything inside. This is great if your available panel space is tight, or you're building 10+ identical machines. Only downside is that I/Os are located on the HMI panel itself, so you'll be running plenty of wires from the panel doors onto the back panel. For this variant, let's go for US7-B10-TA30 (7" flagship built-in) which goes for around $1250 here.
Of course take these prices with a grain of salt. My tax structure here in the Balkans may be different, and your local Unitronics dealer will probably give you more accurate price.
Good hunting!
-
20 hours ago, Ausman said:
Could you please put up screenshots of your ComInits, for both 1 & 2
Here!
I am using COM1 for Modbus, and COM2 is unused at the moment (no serial port card) but I've initialized it.
20 hours ago, Ausman said:yet you are doing 485 on the plc, which at the speed you have is not a fast process and allowances have to be made accordingly. But also please explain the "232" setup.
So, I connect a RJ11 (6P6C) cable to a SUB-D9 adapter and then to a USB-to-Serial adapter and to PC. This works because Vision serial ports enable RS-232 signals even if port is initialized in software as RS-485.
On the PC I use these two software to test out the Modbus:
1. Modbus Slave by Witte Software
2. pyModSlave - free
They both work fine, and I've been able to simulate Modbus traffic over COM2 and TCP/IP, with my PC acting as a slave device.
-
I am debugging COM1 port while being connected to Vision PLC over Ethernet. So it should not interfere.
The devices that Vision is talking to are no more than 0.5 meter distance from it. They are powered by same +24V supply as the PLC. So there should be no separate grounds or high voltage potentials. I have even tried taking GND pin of Vision COM1 port and connecting it to GND pin of the device, and still nothing.
I do have capabilities to debug this on electrical level (oscilloscope, logic probe), but I thought that maybe there are some tips or undocumented stuff about COM1 port, before succumbing myself from system integrator to hardware hacker mode.
-
Few days ago I had this happen to me a second time: Vision RS-485 doesn't seem to work on COM1 port.
First time it was a V570. I connected COM1 port to a VFD using RS-485 pins 1 and 6 on 6P6C connector. Speed was 9600 bps. The communication didn't work. It started working when I connected it to COM2 port.
Second time it was a V700. I connected COM1 port to several transmitters using Modbus RTU. Speed was 9600 bps. Nothing worked. The problem was not in the software, because I connected COM1 port using RS-232 to my PC with a Modbus slave simulator, and Modbus comms worked perfectly fine over RS-232. So definitely it's something in the port hardware or in the OS of Visions.
I've checked the DIP switches, and tried both termination on and off. Total cable length doesn't exceed 1 meter. I've tried with external 120 ohm termination resistors on and off. Double checked port initialization, nothing. Nothing made RS-485 work on COM1 port.
COM2 add-on port work fine with RS-485.
What could I be doing wrong? Has anyone else had a similar problem? What could be the workaround? Maybe the 9600bps is too high speed?
-
Great, thanks for this! Should be pinned.
-
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.
-
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.
-
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.
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!
-
The function works alright.
I've also made my own function with creates a full timestamp string using two calls to RTC to ASCII v2.
-
Okay, I'll give it a try. Thanks for the find!
-
Yeah, but that's a custom function and seems like an overkill.
Vision had a built-in "Numeric to Bytes" function which worked fine. There must be something similar in Unilogic.
-
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?
-
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!
-
2
-
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.)
-
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.
-
1
-
-
Okay, thanks @Joe Tauser, that sounds like a sensible solution.
I noticed option "IO Configs" in Uni-I/O configuration, but it's sad it only refers to add-on modules, not to primary controller configuration. Would be great if it could be somehow updated to work with controller variants.
-
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?
-
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?
-
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.
-
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.
Upgrade of software verions
in UniLogic Software
Posted
I've got about 10 different plants I manage on per call basis, plus around 5 new one-time plants per year which I just automate and forget.
Out of them there's 2 which are in 24/7 operation. When a software patch is needed, I can't simply shut down the PLC running the process. That's why it's important to update OS at downtime, so when the patching time comes, I can download the new app without restarting the PLC.