Flex727

Forcing inputs on and off during Online Test can be a bit of a pain. I wish we could force inputs with a single left click just like Memory Bits. This is another good reason to buffer your I/O. If the input is buffered, then you can insert a test MB to turn the input buffer bit on and off easily.

I think they can be obtained for about $40 each. We always struggle to have enough digital outputs and these look like an inexpensive way to add more. The caveat is that we have to be willing to endure the delays as compared to a relay attached to an I/O module (and potential reliability issues?). I should have one in hand in a couple of weeks and will play with it to see what I can make it do.

Anyone ever tried to communicate with one of these devices with Unitronics PLC? Ideally, I'd like to be able write to the relay address from the PLC using Ethernet. http://kmtronic.com/modbus-relays.html

Why not just program like a thermostat? Set a minimum temperature and open the valve when the temperature is below the minimum. Close the valve when the temperature is at or above the minimum (or the reverse - not sure what valve you're opening and closing). I would be cautious about using Pulse-Width Modulation on a water valve since you might end up with a lot of water hammer or excess wear and early failure on the valve itself.

This is not a problem with your linearization. Minus 25 is the correct output for an input of 0. If your wiring and other hardware is correct (and you have MI 0 assigned to AN 0) you should always get a minimum value of 204 at MI 0.

I totally agree with HigHTech, but I have found that if you have more than 4 or 5 screens on the Samba, you will have a big problem with memory. This is especially true if they are even moderately complex screens with a number of elements on each. I suspect that will be your number one problem with memory limitation when you move from the V350 to the Samba.

Move those operand addresses FIRST before exporting.

Yes, I just had a configuration issue (port numbers weren't addressed properly). These PLCs can definitely act as both a Master and a Slave simultaneously.

Do you have a Snap-In module attached? I've had that happen when the module is not fully engaged.

Perhaps the Unitronics developers didn't handle the error message in the most elegant manner possible, but fundamentally they are offering you two touch choices that are necessarily going to be in conflict. Clicking the "Keypad Entry" box will cause the touch to bring up the on-screen keypad to enter the ASCII data that will go into the vector starting at MI 110. The "Touch" box will allow you to use the displayed ASCII variable to perform some other action in the ladder by making the assigned MB go high when touched. These are two different functions and you can only choose one.

Yes, but also the text and diagram show a vector length of 10 starting at MI 50 and ending at MI 60. It should run from MI 50 through MI 59 or Run from MI 51 through MI 60 (or else change the vector length to 11).

I'm pretty sure that's a typo in the Help file. Perhaps someone can get Cara Bereck Levy's attention on this.

Very true, HigHTech! And thanks again for your help.

This project continues to challenge. Not only have I choked several ladder subroutines, but I ran out of transition contacts. I've never done that before with an enhanced vision PLC. It's been a real learning experience as I had to go through the program and determine if I REALLY needed that positive transition contact (e.g. for a button press, etc). Obviously for a button press to navigate to a different screen, a PT contact is absolutely necessary, but to RESET most alarm latches, it's not that important (as long as the SET RUNG follows the RESET rung, not before). I also changed my logging routine to the more sane method suggested above by HigHTech. I had to move well over a hundred MBs to a vector, but it cleaned up my program nicely and the EVENTS TRACK FB works very well for this application.

Just use binary text or binary image buttons with TOGGLE turned on, then have a ladder rung for each button with a positive transition RESETing each of the other buttons.

For some reason the file size limitation is cumulative. You have to go to your Profile/Edit My Profile/Manage Attachments and delete some of your previous attachments.

I just choked another subroutine. This one had 273 ladder rungs with no Function Blocks at all - just ordinary contacts & coils and a few timers, and none of the rungs were very complex. The reason this subroutine had so many ladder rungs is because I normally have one subroutine just for Inputs (and another for Outputs) where I buffer each Input and add some logic to enable the user to convert the Input from Normally Open to Normally Closed, if needed for the future. This particular project is a beat down as it has 135 Inputs (and almost as many Outputs). This got me worried that I might run out of project memory, but apparently no worries there:

Yep, that would be great if all the events were in a vector. Assigning or moving all the event MBs into a continuous block is more trouble than it's worth right now, but I'll keep it in mind on future projects. The primary reason I don't use the Event FB is that it is extremely difficult to troubleshoot and I hate dealing with it. Considering the complexity of the current project I should have reevaluated my general habit in this regard. Thanks again, HigHTech! By the way, I'm still looking for the answer to my original question.

Thanks for your interest, HigHTech. This software is being written exclusively for a specific customer and I would prefer not to send it out without their authorization. I will try to provide more detail though. See attached to see what is inside those function blocks. It's really pretty simple - I want to log the date and time (and event name) to a data table each time one of 130 events occur. For instance, in the ladder rung I attached above, an operator might push a button (binary text switch w/toggle) on screen to disable RSU 1. Pressing that button causes MB 8001 to go high and that positive transition initiates the addition of a line to the data table, as stated above. I see no reason to add complexity by using an additional MB that gets set and reset when the data table entry completes because the data table operations occur within one PLC scan with no problem. My purpose with this thread was to try and understand the source of the compile error, however I am certainly open to learning a more efficient way to create this data table log. Here are the 3 function blocks from the ladder rung above, in order, and a look at the data table structure:

Yes, they all need to run. Basically, I'm logging events to a data table. The 3 functions are: 1) Copy all rows of the data table down one. 2) Copy a single row from a different data table that lists all the events by name into the first row. 3) Write the date & time that I've already converted into a string into the first row of the data table. The 130 rows represents the approx 130 different events that the customer wishes to log. Here is what it looks like:

One issue I find extremely annoying is that when I copy a variable that allows a keyboard entry (timers, numeric, ASCII variables, etc) the description field, which shows up as the prompt on screen for the operator, is deleted and replaced with a generic "Variable nnnn". I understand this field is used to establish some form of unique name for these variables, but how about leaving the description in place and just appending "(nnnn)" so that it is easier for the programmer to get the right description in the field?

Have you reviewed the example projects included with your VisiLogic installation?

I occasionally get the compile error 55 - "Subroutine ladder data size exceeds limit. Split subroutine to solve problem". Obviously the subroutine is too large for some reason and it's really no problem to split it up, as suggested, but my question is: what specifically causes the problem? Is it the number of ladder rungs or the total data size of the subroutine (meaning a small number of complex ladder rungs or a large number of simple ladder rungs)? The subroutine that I am currently working on that triggered the error has 130 ladder rungs, including the RET function. That doesn't seem like a lot, but nearly every rung is executing 3 different Data Table functions, which might be data intensive. By the way, I can find nothing in the Help file about this error.

I just installed the app on my iPhone and tried it out. It works! And it's pretty cool. Great work!

Another option, rather than change the controller, would be to add the cheapest controller (V130?) available with an SD slot. You could then add a little code to ship the data over to the new controller and store it on SD for retrieval. This would be not unlike an I/O module with SD.