Phil Salkie
-
Posts
59 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Gallery
Events
Blogs
Downloads
Articles
Media Demo
Posts posted by Phil Salkie
-
-
If you're just trying to decide if any of your 100 thermocouples has failed, consider either using a loop, or searching the table of MB bits for a "1" value using the "VECTOR FIND" function block - you'll either get a "-1" result showing that all thermocouples are OK (no "1" values found) or the index value of the first failed thermocouple. Much, much better than making a huge string of normally open contacts.
-
No, visiligic can accept only 1 connection. (How would you show the Operands values and HMI display of remote access when several PLCs connect to Visilogic?).
It wouldn't make much sense right now, as VisiLogic only supports having a single program open at any one time. If a future version were to support multiple programs being open at once (like almost any other modern application) then having a connection open for each program would be sensible and potentially very useful (think debugging networked PLC applications without having a laptop for each PLC.)
The new Download Manager also doesn't support Listeners since it problematic. When you use the Downloader you tell it "I want that application on that PLC (by a givien communication settings)". When having several PLCs connected to the same Port, how would you know which application should be downloaded to which PLC?
Well, the PLCs can have unique names, and must have unique IP addresses. That can be a way of sorting out which PLC is which, but I don't really see the benefit of having multiple simultaneous connections to the Download Manager, unless I'm missing something obvious...
-
If you're using compensating cable (that is, extension wire which has the same alloys as the wires of the thermocouple) you shouldn't be creating measurement error with the wires themselves. Are you using thermocouple terminal blocks? If you land the thermocouple on a standard terminal block, then land the wire on the other side of that terminal block, you are essentially adding in any temperature difference across that block. We keep compensating terminal blocks in stock for our customers who are involved in temperature sensing applications.
As for linearization, you can more precisely calibrate your thermocouple input by sending the input signal through a linearization function block. That block gives you a linear transform between two ranges of values - for example, if an analog input gives you a value between 0 and 1000, you can use the linearization block to convert that to a span of 0 to 250 pounds. (I would usually make that 0 to 2500, then show my display with one decimal point to preserve measurement accuracy.) In the case of temperature, you can set a low and high calibration point, place the thermocouple in a low temperature, store the value it is producing and enter the value it should produce. Then do the same for a high temperature - that will correct the end-points of your measurement range, and (all things being equal) you should have a much more accurate temperature reading within your working range.
-
Considerably less than using a timer, which adds an average of 1/2 scan time each time the timer turns on. The SB3 method will add up to 1 timer period at the beginning of the timing, and 1/2 scan time to the overall amount, but since the time base is constant and not dependent on the scan of the program, it should work as well as using the RTC to UTC method, and almost as well as counting 2.5ms interrupts.
-
So if I use MI variables inside a "Formula block" I haven't to take care of intermediate calculation (exept for overflow on 32bit) because they're done in 32bits and not in 16, and if I want max precision on integer part of the result I have to do the division at the end of calculation.
That's true of _any_ integer mathematics anywhere. For example, in the real number (infinite precision floating point) world, ((X / 10) * 10) = X, no question about that. However, in integer-only math, if X is 4, then (4 / 10) = 0, remainder 4. and 0 * 10 = 0, so your result is obviously not what you expected. If you reverse the order of operations, making intermediate results larger instead of smaller, then you would rephrase the formula as ((X * 10) / 10), X * 4 = 40, 40 / 10 = 4. This works until you overflow the internal 32-bit integers.
If I use ML I have to take care of intermediate possible overflow.
That's true of MI or ML - you always run the risk of an internal overflow with no warning - it's just easier to do if the sources are 32-bit integers.
If I want the best result I've to force some MF -> calculation are done in MF -> overflow quite impossible... But in that case, if I'm using all the 25 MF available in the PLC, do I risk to loose some data?
The internal calculations of the function block are not done in any of the 25 MF registers that are available to the PLC program, so your data is safe - similarly, the intermediate results of the 32 bit integer calculations are not done in any of the PLC's ML or DW registers. If you are using all the MF registers for other things, all you have to do is use some floating point constant in your formula - such as multiplying the result by 1.0000001 (since the formula parser doesn't recognize 1.0 as a floating point number.) in order to force the entire calculation into floating point - the sources and result can all be integers, but the calculation will take place in floating point.
-
I just put up a Blog entry which touches on this exact issue - have a look at it here.
What you seem to be running into is the fact that when you try to accumulate time values, you have a small amount of error due to the scan time of the PLC. It's possible to get around this by using timed interrupt routines and counting up time in 2.5 millisecond increments - but for longer values, it's easier to use the RTC->UTC conversion function to get a value for "Now" in seconds, save that value as your "Start" time, then calculate elapsed time with ("Now" - "Start").
-
1
-
-
If I may rephrase the question: "Are the internal calculations of a FORMULA block performed in 16 bit integers, 32 bit integers, or floating point?"
The answer would appear to be "That depends" (I've tested this on the V570, your results may vary). If no floating point constants or variables are used, the internal calculations seem to be done with 32 bit integers. If a floating point constant or variable is used, then all internal calculations are done in floating point.
A=MI0
B=MI1
Result in MI2
The formula:
(A * / 10000
(divide by ten thousand)
works properly throughout the 16 bit integer ranges of the MI sources, so long as the result will fit into a 16 bit integer.
A=ML0
B=ML1
Result in ML2
This formula:
(A * / 10000000
(that's a divide by ten million)
will give incorrect results for A=1,000,000 and B=1000 because the intermediate result (10,000,000,000) is larger than a 32 bit integer.
However, this formula:
(A * / 10000000.000001
(still effectively dividing by ten million, but forcing the calculations to floating point)
will give correct results with A=2,000,000,000 and B=10,000,000 (the end result being 2,000,000,000 and the intermediate being 2 * 10^16)
Oddly enough, the FORMULA block's parser interprets 10000000.0 as an integer, not a floating point, so I had to put that extra .000001 on the ten million in order to force a floating point calculation.
And, as always, check the ranges of your variables before doing a calculation - there doesn't seem to be any SB to tell your program that an integer calculation has gone out of range, so if you were to have a FORMULA block working in the integer range, and an intermediate calculation overflowed the internal 32-bit registers, your program would have no way to know, and it would basically be operating on a random result - that would be, at best, BAD.
-
I connect to a V570 via a 24-port switch all the time, for what that's worth. Could there be a cabling issue, or a bad port on the switch? Is it a 10 base T hub and your computer has its port locked to 100? If it's an unmanaged switch, it should just forward any traffic it sees regardless of the IP address ranges involved, so I'd really suspect a hardware/cabling issue.
-
Using 8.6.2 - If I export a file with the extension ".xls", then I get a properly formatted file containing no operand descriptions at all - this used to work, and now doesn't. If I export a file with the extension ".xlsx" I get the same message as you got - "The Excel file you have selected cannot support the exported values" - I've never actually seen VisiLogic make a proper .xlsx file. I believe this has all been broken for a while, I have just been re-using old export files, modifying them, and then importing to my new projects, so I forgot to report it.
It used to be that it was necessary to have Microsoft Excel installed on the machine in order to export or import .xls files, I assume this is still the case.
-
Were you reading the output in the same network that you changed it in? Remember that the Unitronics follows an international PLC standard which states that no bit statuses change during the processing of a single network. Therefore this:
------------------------ MB0 MB1 -|P|-----( )- MB0 MB1 MB2 -| |--| |---( )- ------------------------
will never turn on MB2 because the read of MB1 gives the status that MB1 had on entering the network, whereas this:
------------------------ MB0 MB1 -|P|-----( )- ------------------------ MB0 MB1 MB2 -| |--| |---( )- ------------------------
will do what everyone in the world (except the standards committee) would expect the first network to do, turn on MB2 for one scan on the rising edge of MB0.
As a general rule, don't combine rungs in networks. If you feel it's necessary or advisable, then look at the STL Quick View to make sure the actual compiled logic does what you thought it was going to do.
-
Is this compare function in a subroutine? I've often built a subroutine, but forgotten to call it from the main sequence program, so it monitors and appears correct, but it is never actually _run_.
-
You'll be using the Protocol:Scan FB to read the incoming data stream, capturing the characters you are interested in to MI registers so that your ladder program can check their ranges and decide which message to send out. Hard to be more helpful without knowing more about the incoming data...
-
In your "HW Configuration" page, you define the hardware you'll be using with your PLC. In those tabs, you'll see entries for the analogue inputs and outputs - assign MI registers for each input and output you'll be using. Your raw loadcell input will now show up in, for instance, MI 400. Now, scale that to match the output range you'll require for your analogue output - the "Linearization" FB will likely be quite helpful there - and place the value in the register you've selected for the analogue output, for example MI 410.
-
I suspect what you've been doing is holding your finger on the screen while applying power to the unit - that is the "hidden" method of stopping the boot process to allow reload after, for example, an incomplete operating system upgrade. To get into info mode, power up the unit, then once the unit is sitting at a display screen (such as the "out of the box" Unitronics animation) touch the screen for four seconds, being careful not to move your finger around. Then you'll see the two boxes allowing you to select between "Enter Info Mode" and "Calibrate Touchscreen".
-
I suspect you're seeing the result of putting a timer current value (which is a 32 bit number) into a 16 bit MI, and winding up trimming off the upper 16 bits of the data. This will only be a problem if the timer preset is large enough that it exceeds the size of 15 bits - the positive portion of a signed integer. (That's about five and a half minutes.)
-
Using three variables is exactly how I do it - if you use a fixed width font, it can look pretty good.
-
If the internal scan time value is not what you are looking for, you can use a timer of 10 or 100 seconds duration and count the number of scans in that time period. You can then divide by some multiple of ten to get various resolutions of timing (basically, moving the decimal point on the result to get scan time in milliseconds, 10 X microseconds, etc.)
-
Starting up V570 ethernet connection from an "new out of the box" condition takes several steps:
Go into the "Info Mode", enter the password (1111), go to "Version", then "Software", and write down the PLC Name that's at the bottom of the screen.
Then hit "Escape" twice, select "Ethernet", then "IP Parameters", and enter your desired IP address and Netmask, then press "Apply".
Hit "Escape", select "Socket Parameters", and set Socket 0's Port to 20256 and the TCP_UDP to "TCP Slave", then press "Apply".
Now go to Visilogic and open your project. Go to "Connection", then "Communication & OS", set "Connection Type" to "TCP/IP Call", check the button for "Favorites", and click the folder icon on that line to open a list of PLC Names, IP Addresses, and ports. Put in the PLC name you wrote down, at the IP address you chose, and port 20256.
After that information is entered, press the "Get OPLC Information" button - you should see the information about your PLC show up in those boxes.
In order to get around having to do this for each new PLC, I have taken to naming all PLCs for a given customer by the same name, since we haven't yet had multiple V570 PLCs on an ethernet network in the plant - we just use it for programming, monitoring, debugging, and Modbus connection to Building Management systems. I put the PLC name, the SD Card password, and the TCP/IP initialization information in the first rung of the program - you can download an example framework program from the link at the bottom of this blog entry.
I then can use the VisiLogic function "Project/Create Project Files" to create a clone file, with project and OS - selecting the latest OS available - and save that file with a name like "ETHERNET" (it has to be 8 characters). I use the SD Card Tools to format an SD Card to Unitronics layout, then put the ETHERNET.c57 file which I created in the /system directory of the SD card. I can then insert that SD card into the V570 PLC, go into INFO mode, select "SD", then "Clone", and "Upload to PLC". That loads the program in, which sets the ethernet IP address and port and sets up the PLC name to the proper one for that customer. Having the SD card with a minimal framework application lets me quickly initialize a new PLC and get it immediately ready to program and monitor over Ethernet.
-
It'd be fiddly, but could you use the "Draw Line" function block in ladder logic to draw in an upper and lower process boundary line whenever the screen is displayed?
-
At power-up, take the current RTC registers, move the whole set of them to a batch of work registers with a vector copy. Change the time of day registers in the work area (hour, minutes, seconds) to the time of day you're trying to check on, and convert the work area to a UTC value. Take the DOW register from the work area, which is today's day of week, and use that to see how many days you need to back up the calculated UTC value to get to the desired day of week - subtract 86,400 times the number of days from that UTC value. That's now the UTC value for the time of day you're looking for, on the day of the week you're looking for. Now compare that UTC to the saved power-down UTC - if the saved value is less than the calculated "magic date/time", the PLC was powered off at that time.
-
My educated guess would be:
y = (((y2 - y1) * (x - x1)) / (x2 - x1)) + y1
Note that all the intermediate calculations are made in 32 bit integers, and if those calculations exceed the 32 bit signed integer range, the "y" result will be random, as none of the intermediate calculations are bounds-checked for overflow.
-
You can have multiple data connections as long as you have multiple communications ports. For example, the V570 comes with two RS-232/RS-422 ports standard, one expansion slot for another 232/422 or Ethernet, plus a CANBUS port. The CANBUS port can be used for PLC-to-PLC communications, and the serial ports can be used for SCADA-to-PLC connections. You can also use the Ethernet port for multiple simultaneous functions.
-
Did you mean to have MB3 trigger the send of the email, but have MB4 get reset after the email is sent? Without seeing more of the logic, it's certainly possible for the rung you have there to be triggered for multiple scans and wind up sending the email multiple times.
-
Yep, this sort of thing can make you crazy. On my XP instance, I'm not running any firewalls or virus scanners/checkers, and I have many of the standard XP services turned off - on your system, it may well be an interaction with a firewall or some system service, or it could be as simple as a bad ethernet switch. Do you have to close VisiLogic to get this to happen, or does just stopping monitoring (or powering down the PLC) clean things up? Have you tried leaving a system monitor window up to see whether it's the VisiLogic process that's hogging the CPU, or some system process?
Serial connection
in Vision & Samba PLC + HMI Controllers & VisiLogic Software
Posted
If you can live with a slower data transfer rate, you can increase the distance. Assuming you only need to collect results once or twice a minute, you could set a rate of 1200 baud, and run your RS-232 signal a few thousand feet without any problems. Alternately, you could put a $60 RS-232 <-> RS422 converter at the PC end, switch the DIP switches to RS-422, and run your data half a mile at 9600 baud.