Phil Salkie

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?

Thanks! Glad to help - I've just posted an updated project file and a new screenshot for the Info Mode rung, I had "Level 2" instead of "Level 8" in the comment and on the first line of ladder.

Haven't seen that behavior - I left VisiLogic 8.6.1 running overnight with a TCP/IP connection doing monitoring of 40 SI variables plus some ladder, no apparent difference in operation after 14 hours. Then again, I don't know that my system is the best testbed, since it's running XP under VirtualBox on a Linux host - but that does give me more ability to see what system resources XP is using. Are you running the latest VisiLogic?

I tried your apps with OS 3.1, Build 19, using VisiLogic 8.6.1. At first I couldn't get the comms to work, then I tried a slower Baud rate, which worked immediately. Then I put a terminator resistor on the interconnecting twisted pair I had strung between the V570 units, and the 500K Baud connection worked. Removing the terminator made it stop working again. So maybe you're looking at an OS issue which was resolved somewhere between what you're using and the latest? Or perhaps it's a missing terminator someplace...

I'd try rolling the OS in both terminals back to a previous version and see if the problem goes away. I had a serial port comms issue with an OS upgrade, and was able to find just what version the problem occurred at - that made it pretty easy for R&D to figure out what the problem was and come up with a fix.

Drawn on the calculation block in question is the phrase "A SUB B = C". Similarly for divide, it says "A DIV B = C". I do agree that aside from that, the definition of order of operands is missing from the help page.

It's not easy to tell without seeing any of what you've done. You could try cutting and pasting the non-functioning binary text box into a new application and posting that application here so we can see it, or possibly posting a screen shot of the configuration page of the binary text box...

> I want to make sure I understand this clearly because I am still a bit confused on what the UTC is for. > I understand that the UTC can hold an integer that tells you where you are in time with respect to the epoch, > what I don't understand is how to get the value itself. If I take the RTC to UTC and send SI 30 to DW 0, am I > going to get the time in seconds from the epoch? Yes. If you put any set of seconds, minutes, hours, etc. in a different set of MI registers in the same pattern as the RTC is laid out, you'll get a UTC result that corresponds to the time and date you fed in. > Does the RTU to UTC account for the year, days, and hours in seconds and add them to the UTC or do I have to account > for all of that in my one DW that is the time since the epoch? The "RTC to UTC" function accounts for all hours, days, months, leap years, and so on, and produces a 32-bit integer which is the exact number of seconds between the Epoch and the RTC formatted date you fed in. It is a one-to-one correspondence - any RTC date within the allowable range will produce one and only one UTC result, and any UTC value within the allowable range will produce one and only one RTC formatted date value. That's all you need to do - give it a date, it gives you a 32-bit integer. You can add or subtract a value (in seconds) from that integer, and feed it to the "UTC to RTC" function, and the result will be whatever date that winds up being. If you want to play with some examples, go to the Epoch Converter Page and feed it some date values. Note that this page uses the Unix Epoch of 1970, not the Excel Epoch of 1900, so the resulting UTC numbers will be off by a fixed amount from the UTC numbers in the PLC.

> I think I am missing what DW the UTC will store its information if you don't call it on a HMI screen and designate > it a DW for it. Am I missing a function block that will call the UTC? Yes - at least on V570, there are two function blocks: "Utils/Clock/UTC/RTC to UTC", and "Utils/Clock/UTC/UTC to RTC". The "RTC" field is the value of the first MI of a group in the Real Time Clock ordering - just like SI 30. The "UTC" field is any doubleword which will hold the 32-bit UTC value.

One of the requirements I frequently find in customer specifications is that Operator Terminals shall have eight hierarchical levels of password protection. The idea there is that an operator, for example, enters the level 1 password to do operator things, and a supervisor can enter a level 2 password to do anything the operator can do, plus supervisor stuff. I have yet to actually see an application where all eight levels were used for anything, but somebody somewhere once decided that eight would be the number, and it's now engraved in stone. So, when I started using the V570, one of the first things I did was to come up with a way to implement those eight levels of password, In today's blog entry I'll walk through creating and implementing a multi-level password system, and throw in automatic screen-blanking and a password-protected "Info Mode" for good measure. I always like to start by defining as many PLC variables as I can, so that as I program I can immediately tell if I've made a typo as I enter operand addresses. So, let's define eight MIs to store the passwords for level 1 through 8 (we'll use MI271 through 278) plus another for the user to enter their password into (MI270). (I usually set the passwords permanently using "Power Up Values" in the Operands table - you could also permanently set only the level 8 password, then make a level 8 password protected page to let the user change the values for the first 7 levels.) We'll define eight MBs for the password status - is level 1 enabled, or level 2 enabled, and so on, at MB271 through 278, plus a "Process Password" bit at MB270 and a "Clear Password" bit at MB279. As it happens, the password status bits will actually be logically inverted - Level 2's bit will be OFF if the level 2 password has been entered (as will Level 1's bit.) The reason for this has to do with the way screen items are controlled, which we'll see a bit later. VisiLogic supports a blind entry field, which allows the user to type in a password that is not shown on the screen - that was obviously built with password entry in mind, so that's what we'll use. Here's a screen with a place to enter the password, a multi-text to show which level of password is currently active, and a button to cancel the password level. (We will put that same multi-text on our menu screen, to show what level is entered, and if no password has been entered yet, to prompt the user to put in a password.) Now, if we have a display component we want to password protect, there are two different ways we might protect it. The most obvious thing is to just make it disappear from the screen if the entered password is not sufficient. That's what the "Hide" variable does for us - we put the MB corresponding to the desired level into the "Hide" field, and if the user has not entered a password at or above that level, the display item will just not show up on the screen. Since the control variable is "Hide" rather than "Show", we make our password bits normally ON, and turn them OFF when the password gets entered. That's great for hiding a menu button that takes us to some restricted configuration page, but what about when I want to let a lower-level user see a value, but not be able to change it without entering a password? That's where the "Disable view" variable comes in. A variable whose "Disable view" bit is on will still show up, but it will be shown in the "Disable view" color (gray by default.) Once the proper password is put in, the variable will then show in its selected color (I usually use blue for variables which can be set by the user) and will be active to touch. Now that we've figured out how our screens will work, let's look at the associated ladder code. Here's the first part of a series of rungs which check the entered password against the various stored passwords, and determines which level has been entered (if any): Here we convert that number to a pattern of eight bits for the various levels: And on this rung, we put in a timeout so that if the password has been entered for more than a preset time, we clear it back out: As I mentioned above, it would also be nice to prevent the user from accidentally switching to the Info Mode password screen (that's caused by touching a blank area the screen for a few seconds.) We can disable Info Mode by putting a Zero into SI 50 - but we'll want to be able to get into Info Mode somehow, so we can re-enable it when a level eight password is entered. I've also put in a 10 second "back door" timer so that Info Mode is enabled for a short time just after power-up - that way, if something goes wrong with the passwords, I can still get into Info Mode: And, lastly, here's a rung which turns off the backlight if the screen hasn't been touched for five minutes - that's less important on the LED backlight than on the CFL, but it's still not a bad idea to turn it off when not in use - I also re-enable it if an unacknowledged alarm is present (indicated here by MB 197): This is a downloadable link to a V570 application file containing all these items - it has been released into the public domain, feel free to use it as a starting-point for making your own V570 projects. To learn more about Howman Controls, visit our web page at www.howman.com

UTC input values definitely won't let you put in a year of 2024, even though there's room left in the 32-bit register for more seconds. Interestingly enough, if you put a date into the RTC past 2024, the clock seems to work, but the UTC calculated from that date is incorrect - there's probably some overrun of a 16 bit variable in the internal calculations for going from Gregorian Date to UTC and back. They can probably fix it fairly easily, extending the function to 2036 instead of 2024.

> Also, when using the UTC, do you have to create a variable in a display to use it? No, it's just a number in one 32-bit register (DW). > I have no desire to display the time and date I just need it so that I can do a UTC to a RTU (DW to MI). If you need to send that value, it'll have to go as two 16-bit registers (MI). You can use the vector instruction "Map Register Bytes" to control which bytes of the source DW go into which byte of each word of the two destination MIs. > Also, I am unclear how you can store a date in seconds with out the hours and seconds remaining. Is the UTC > basically just using very large numbers to corespond to a particular date? I think my main issued is how you > go from a date to just HH:MM.SS. Am I reading the help section incorrectly? The function returns a 32-bit integer which is the number of seconds since the Epoch. No hours, minutes, days, years are returned in the result - just a huge number of seconds. > From my understanding if the zero was set at 1900 - 01 - 01 00:00.00 then when the 32 bit binary number was at > 1111 1111 1111 1111 1111 1111 1111 1111 that would give us an integer of 4294967295 seconds which when converted > would give us a value of 136.19251950152207 years. How are we going to get ok readings until 2024 and not 2036? That's a good question. Maybe somebody miscounted when putting together the manual? > Is because the maximum MI is 32767? I don't think so, no. > If what I am saying is right then one UTC can be used for when the power is lost but still a significant amount > of code will have to be written to account for the actual time elapsed in years, months, days, hours, seconds > with multiple RTU (MI) numbers If anyone were to actually care about that, then, yes. Remember that "Year" and "Month" are variable lengths of time, so it's meaningless to say "This system has been down for two months, seven days" - which months? Do you count from the start of a month, or backwards from now? If it's been down for 32 days and it's the middle of the month, is it one month and one day, or one month and fifteen days? You're much better off to just say "342 days", or "48.85 weeks" or something like that. Remember also that in the specific case of how long the system's been powered down, there's a lithium battery involved which will limit the maximum duration to much sooner than 14 years from now. > or can XI (no information on this in the help) or SI be used to cover longer lengths of time? An XI is more or less like an MI which can be accessed faster, and doesn't retain its value on powerdown. An SI is something that the system calculates, or you put a value in to modify the system's operation. Neither of these will help with longer lengths of time. The general method for handling this problem is to use 64 bit numbers for UTC, or to move the Epoch date. If we had a different function which returned and manipulated UTC values based on a 1970 (Unix) epoch instead of a 1900 (Microsoft Excel) epoch, we could get another 70 years out of the existing setup. Another possible cheat would be to have a "Days since the Epoch" value which was separate from the time of day, but that gets messy when you want to add and subtract values.

It's the Mayan apocalypse - turns out that they were off by a base-twelve decade. (I suspect that by then, we'll have a new function block which moves the epoch from 1900 to 1970 and buys us another 70 years, or gives us a 64 bit UTC value. Trouble is, of course, that 32 bits' worth of seconds is about 136 years...)

The PLC Name being different on each new unit should be more than enough security to protect the unwary - I'd vote for each PLC to come out of the box at the default IP address and with all four sets of ports set to something known and useful, and that pushing the "Set Default IP Address" button should set the ports to the default as well (or should give a dialog box which offers that option.)

I'd say you're doing it wrong. Use the RTC to UTC function block - that gives you a value in seconds from the epoch (1 Jan 1900). If you store the UTC value in a DW register once a second as the last thing you do in the main block, then on power-up you can calculate UTC and subtract the stored value (which would be when the PLC was powered down.) That result is the number of seconds the PLC was powered down - divide by 86400 (seconds per day) to get days powered down.

So I'm easing my way back into VisiLogic land, in-between phone calls from TV trucks. The other morning I get a call from one of our techs on a startup somewhere in Texas, telling me that the customer is requesting that all the panels on the "A" side of the facility have their primary power feeds fed from the "A" side breaker panels, and that on the "B" side, "A" side breakers should go to the secondary power inputs. For this they wake me up? Just swap the feeds on the "B" side, right? Unfortunately, when we laid out these panels, we made the decision to label the primary power feeds as "Power Feed A" and the secondary feeds as "Power Feed B". So, now that the customer is hooking up power, they think of "A" as "Side A", not "Primary", and half the panels are wired up backwards, because the panels on the "B" side need to have "Power Feed B" be primary, not secondary. So, we offer to relabel things "Primary" and "Secondary", but the customer really likes "A" and "B" because it matches the names of the sides of the building. OK, we rewire half the panels to make "B" be primary - problem solved, right? Not so fast. It turns out that "Using Power B" is one of the alarm texts - on half the panels, it'll have to be changed to "Using Power A". Similarly, the input designation will have to change on the signal telling us if the panel has lost its primary power feed. So, I figure I'll just have the PLC program look at the network address - if the panel's on side "B", the ladder can just swap the text of the alarm. Except that I can't - the texts are stored in String Libraries, which are in Flash memory and are not changeable by the PLC program. OK, says my technician, just make a separate version for the "A" side and the "B" side... And, yes, I could have done that. It would have been easier and quicker - but it wouldn't have been the right thing to do. Splitting software into multiple working versions - referred to as "Forking" a piece of software - is something to avoid if at all possible. If you have an "A" and "B" side program, which are mostly the same, then in the future you've got to be sure that any changes you make to "A" are also made to "B". You also have to be sure that if a PLC needs to be replaced or have its software reloaded, that the correct version gets put in. It means that if the customer wants to have a spare on the shelf, they now either need two spares, or they have to be concerned about keeping SD cards with the different versions on hand. Forking is one of those things that seems quick and easy, and winds up causing you massive headaches a couple years down the road. So, I thought of a couple of ways to get around the problem - using two different alarm numbers in the controller depending on what side it was on, then swapping the numbers back before passing the alarm list off to the master PLC, or putting the alarm list into the string table twice, one starting at zero, and one at five hundred, and having the list display routine add five hundred to the alarm number if the controller was on the "B" side. It all sounded like just too much effort, and I was about to hold my nose and save off an "A" and "B" version of the software, when I realised: String Libraries aren't just for multiple languages anymore. Each index in a String Library table has multiple entries associated with it, and by far the most common use for these entries is to support easy switching between languages. If, for instance, instead of just placing the text "OPEN" on the screen, you use "String From Library", you can have "OPEN", "ABIERTO", and "OFFEN" stored at one index. Then with a single function block, the PLC can select whether to use the first, second, or third String Library, and the text on the screen will switch from English to Spanish or German. Carry that through the entire HMI program, and you can easily have a program where the operator can set the display's language with one keypress. Now, here's the fun part - I wasn't using multiple languages, but I _did_ need to have a handful of String Library entries change from "A" to "B" or vice versa, depending on the network address. So, I used .csv import to load the exact same list into the first and second Library, changed the "A" and "B" on the alarms and input names in Library 2, and set up a rung of PLC code to switch to either Library 1 or Library 2 depending on network address. Boy, did _that_ make a mess! The HMI became unresponsive, the screen flickered constantly - I knew I'd done _something_ wrong, but what? Aha! I had made MB219 be "This Is Side B", then used a normally closed MB219 to set String Library 1, and a normally open MB219 to set String Library 2. However, the PLC redraws the entire HMI page every time the String Library is selected, even if it's the same library as it was last scan. So, I quickly added a normally open SB2 to each rung so that the Library is only selected at power-up - I thought about using transitional contacts [P] and [N] on the MB219, but felt it would be better to use the SB2 and be sure that the proper library gets selected each time the PLC gets powered up. That worked perfectly, and I now have just one software version for both sides of the plant, plus I have an extra tool in the toolbox - using multiple String Libraries to change a PLC's configuration. You could use network address, a password protected setting in a configuration screen, or even a hardware jumper on a spare input (a method that protects against accidental mis-configurations) - just have some way to let the PLC know which way to set its String Libraries, and you may be able to avoid having multiple versions of the same PLC program kicking around, waiting to trip you up five years in the future.

I'm running 8.6.1 on a stripped-down XP install under Virtual Box on Kubuntu Linux. While my initial experience with Version 8.0.0 was similar to yours with crashes and lockups (but never with any data loss!), each intermediate version has been an improvement over the last, to the point that I can't recall the last time I've experienced a VisiLogic crash.

In regards to the alarm screen, I've done much the same - built a system allowing some alarms to auto-reset, while others must be acknowledged, has status bits for each alarm showing unacknowledged, trigger present, and alarm state (very useful for triggering LEDs - flash on unacknowledged, solid once silenced but still present). It has scrollable alarm screens showing alarm text (with the text variable) and status (that's where I change the colors based on trigger state and acknowledgement, since each status field only has two text states and two colors) and one showing alarm text and the alarm's time stamp. I also show the top three alarms at the bottom of the main display. This screen and my digital I/O diagnostics pages were the reason for getting R&D to add a .csv import to the string table editor - trying to type in long alarm lists and lists of I/O names into the original editor was not much fun, especially when I already had the data in a gnumeric (open source) spreadsheet. (The excel import had some unusual restrictions, including using hidden excel-specific data and not being able to import a line which hadn't previously been exported, making it tough to add new lines from the spreadsheet...) Seems like great minds think alike!

Can you get away with just using a "Text" variable, and setting its value to an "Indirect Select Library String"? That won't let you touch the value and modify it (select a value from a list), but if you're just looking to _display_ a value from the string library, it works fine.

Is the cable the right way around? Make sure the end that says "PLC" is attached to the PLC - that's bitten us more than once.

Not to kibitz, but none of the V570 units we've shipped have ever come with usable default port numbers set (and that's quite a few units). Also, there's a button in info mode to set default IP addresses, which _doesn't_ set up any default ports. Since setting up ethernet comms on the V570 is more than a one-step operation, I've given all my service techs an SD card which has a clone file for a simple application which sets up the ethernet port and establishes a default generic PLC name. That way, when my techs need to set up a new V570, they just pop in the SD card, clone the PLC from the card, and they're ready to hook up VisiLogic (that way I'm also sure of what OS version the V570 is running.)

It's been a couple of weeks since I've run VisiLogic - that's a bit unusual for me lately, since I generally don't go a day without doing something or other on a Unitronics system. The reason is that I've been spending my time on two of the nation's newest mobile HDTV production trucks, installing control systems which combine an embedded Linux computer with networked frames of Mitsubishi PLCs and a cross-platform PC GUI written in Perl/Tk. Working as a controls systems integrator has its benefits - a fair amount of travel, exposure to lots of different industries, the ability to pick up the occasional cool story - when I meet someone new, one of the most common questions I hear is "Controls Engineer, huh? How'd you get that job?" The answer I give is, I admit, a bit cryptic: "I was a Television Engineer for ABC Networks in New York." That leads into its own story, which I'll try not to make too boring (and I'll bring it back to Unitronics territory at the end): You've all seen a TV Camera with a red light on the front, right? Well, did you ever stop to think how that red light knows when to turn on? Back in 1985, our engineering group at ABC was presented with a problem - we were installing a new little TV studio which would allow us to feed different programming and commercials to different sections of the nationwide ABC network. This meant that for the first time, more than one studio could be "On The Air" to network at once, and the red lights on dozens of cameras and hundreds of TV monitors would need to react accordingly. (Today, that's one _small_ truck worth of gear...) The technology we used to turn those red lights on was bank after bank of slide-matrix switches - all set up by hand for each show, and all physically wired to the various devices, which all had to have compatible voltage levels (or have frames of interposing relays). Our quick calculation of the number of those switches required to get the red lights to do what we now needed them to do pointed out that the matrix switches would take up all the room we had reserved for the actual TV monitors, plus another rack or two. Time to look for another answer, as finding a bigger room wasn't an option. One of our engineers happened to be looking through a trade magazine and saw a new device from Mitsubishi - a "Programmable Logic Controller", or "PLC". It could have hundreds of inputs, and hundreds of outputs, and had a CPU which could read in the inputs and control the outputs. This would allow us to replace seven or eight racks full of matrix switches with a frame which could mount under a console, and be controlled by that new thing which I was one of the department experts on - a "Personal Computer" (this was just before that mainframe company got into the PC business.) We could also save patterns to floppy disk and load them back up, saving many hours of setting up and checking out the tally light configurations. Well, the software turned out to be much more of a project than we had envisioned, since we were trying to emulate a matrix switch with tens of thousands of crosspoints - more crosspoints than the controller had memory to store. I tried saving a compressed matrix pattern as data tables in the controller's memory, only to find that it took so long to scan the data tables that the red lights would only update every few seconds - far too slow for the precise timing of television production. The eventual method I used was to reverse-engineer the language used to program the Mitsubishi controller, and have the personal computer software write its own PLC program and download it to the controller - something the manufacturer didn't support, and wasn't sure would even work. But work it certainly did - that system was the first of a whole series of PLC installations at ABC networks, and PLCs were deemed by the engineering department to be the most reliable equipment in the entire plant. Eventually I moved over to work for the distributor we had bought the controllers from, and who had helped us get un-released components and untranslated documentation via air cargo from Japan in order to make a PLC do something that was considered impossible. That distributor was Howman Controls, and twenty plus years later, I still work here, and we still do some off-the-wall projects, and we still make Tally systems for the broadcast industry using Mitsubishi controllers. However, this latest installation has got me thinking - what if I were to use a V570 system instead? Although the PLC frames don't currently have any operator interface device at all, if we used a Unitronics I could provide a diagnostic display allowing for easier installation, testing and troubleshooting. TV trucks take an amazing pounding as they drive around from venue to venue, and it's not unusual for interconnecting wiring to fail, or connectors to become dislodged - having a readily accessible display would be a great feature, and given the difference in pricing between the two PLCs, it's essentially a free feature. PLC to PLC networking is also a built-in on the V570, so that would now be standard instead of an extra-cost item. The faster processor and native data-table handling bypasses the need for the reverse-engineered PLC programming trickery I've used in the past, and the availability of ethernet and RS-422 communications would let the Unitronics communicate with the various routing, control, and display devices on the truck, potentially giving smaller installations the same power as our current Linux/PLC hybrid top-of-the-line systems. I can see there's going to be quite a bit of R&D work in my future...