Damian

Post your code and we can help fix it. What is your gateway set to?

If you are trying to read it all in on one telegram it will be too large. You will have to split it up. You are limited to 256bytes including the header and trailer. 4*64 is exactly 256. It will need to be split up in at least 2 telegrams.

This is an example of normal translation Every thing flows left to right as expected. Now lets add a contact in series with the INC block. As you can see the left to right execution has been broken. It actually went back and executed the comparator twice! It interpretted the ladder as if it were actually written as so. So you have to be careful how you structure your rung. Now watch what happens when I add another test/operate condition in series. In reality, the translator actually broke the network up into three separate rungs. Each time it redundantly re-tests all of the preceding conditionals. Only problem is it is only redundant if the conditionals don't change during the rung execution. The moral of the story is, be careful when writing rungs that both test and operate on the same operands. The results may not always be as expected. When in doubt, double check the STL just to make sure it jives with what you wanted.

Sorry for taking so long to respond to this. Your take on how you perceive what is going on in the background of the PLC is for the most part inline with how I would interpret it.. Ultimately it is just a microcontroller and the ladder software is just window dressing to make things easier to program. Your view of subroutines though is not quite right for the reasons Joe pointed out. They allow you to organize your code in the same fashion that a book may have chapters. I just had to modify a Mitsubishi program a few weeks ago where the whole program 500+ rungs of code were all in one big subroutine. I spent 90% of my time using the scroll bar to search up and down for the relevant logic I was looking for. Arghh! I still have that headache. In my programs you will find there are some very common subroutines that always pop up. Such as HMI Alarms Auto Manual Inputs Outputs Virtually every program I write has at least these. Now if I want to diagnoise alarms I can go right to the code where they are at etc. My Main subroutine is generally just a place where I put all these subroutine calls in the order I wish them to be executed. The modules are also handy for organizing your code. For example, I may have 3 axis of servo and each one of those has a few common subroutines. Axis 1 Manual Axis 1 Auto Axis 1 Reset etc. Axis 2 Manual Axis 2 Auto and on and on. I will give each axis its own modules to help create and organizational tree for them. Just keeps things neat and tidy. The type of subroutines you are used to are what in PLC ladder land are usually called UDFB (User defined function blocks). These allow you to pass parameters to and from a certain chunk of code that perform a function on them. Visilogic unfortunately does not support this capability and has often been a request here on the forum. With the use of data tables, it is possible to mimic the functionality of a UDFB. It is cumbersome enough to where you really need to have a good reason to bother doing it that way. The biggest reason for having UDFBs is for making portable code. This way you can import that UDFB into another project later on without having to worry if that code was written using operands that were already in use by other code. Some day, hopefully in the near future, I believe you will see Unitronics software with this ability. But probably never in Visilogic. Next ............. that execution sample I promised you.

My first suspicion would be that the + and - data lines got swapped on the two that are not working and then swapped back at the final node. I would double triple check the wiring. Double Triple check that the jumper setting for the two that are not working match the RS485 setting that is on the ones that are. Double Triple check the comm setting Baud, parity etc of the non- functioning units. Double Triple check that you didn't accidently give two of them the same node number/ address. Next thing to try is powering up all the slaves first, and then power up the master some time after. Next, power the system up with one of the units that doesn't work unplugged. Does it affect the other units. Repeat with the other non-functioning unit. Describe you wiring more. How did you daisy chain your signal from port to port physically? What type of wire are you using? How did you implement your terminating resistors?

This one is an international show so probably not cost effective for a small local distribution.

At IMTS this week in Chicago. I've seen about 4 or 5 V570s on the various machines here already an I still have 1/3 of the machinery to check out. Suprised that there is not a Unitronics exhibit.

"From what you saying, Visilogic will always execute a normal coil at each scans even the preceding ladder conditions hold false (energize it if true, and de-energize it if false), while a Latched Coil will only be executed with ladder conditions hold true." That is correct. And to finish it out, both LATCH and UNLATCH (SET and RESET) coils only execute when all the preceding logic evaluates to true. Regarding the STL view I don't believe there is any official documentation on it, but this is how I have interpretted them. ! Load the following condition into the accumulator/stack = Assign the logic evaluation of the accumulator/stack to this memory location & AND the value in the accumulator/stack with the state of this memory location and place in the accumulator/stack &N AND the value in the accumulaotr/stack with the INVERSE state of this memory location and place in the accumulator/stack. / OR the value in the accumulator/stack with the state of this memory location and place in the accumulator/stack the LB disignators are branch buffers that retain the value of the evaluations. My guess is that it stands for "Logic Buffer". With large networks you will generate a lot of these. Essentiually one for every paralllel branch you create. As I mentioned above, it is "remembering" the state of these evaluations so that it does not have to go back and re-test. The tricky part is that the translator does not always remember these evaluations and will in some instances go back an retest the logic. Later this evening I will grab an example I have in another post to help explain that better. Yes, your undertstanding is correct regarding the re-execution. If you have series logic where you had to satify condition NOT X and A and B to set X and then you have another condition C after that to evaluate Y then it may go back and re-evaluate NOT X & A & B which will now evaluate to FALSE and C will not energize even though it should have under strict left ot right rules. It tends not to have logical significance unless your logic is writing to the same memory that you are testing in that same network (which is a pretty normal thing to want to do - i.e. "a self sealing coil"). Since this is your first PLC application I would highly recommend reading through a section in the Visilogic help where it explains the order of the scan, when things like I/O and HMI memory are updated and refreshed, when the system memory is serviced, an the rules that are used to govern the ladder execution. Whenever I am learning new PLC software this is usually where I start to try and understand better what the controller is doing under the hood. With your background in VHDL your going to find this stuff a breeze. Your asking all the right kind of questions and ultimately you will end up with a much deeper understanding of what your doing than average user.

Gosh! You think they were punishing me? My mother always said I have a knack for letting my my mouth get my butt in a whole lot of trouble. PS What is that smiley supposed to be?

Hi Simon, That was the way I used to do it back when the new forum came to be. But the attachements count against your upload quota and I was in a short time unable to upload anything anymore. I had to beg Cara to up my quota, you know..... on my hands and knees groveling and all that. I was then given the understanding that "pictures" were meant to go through the Gallery and that attachments were only meant to attach programs. It seems like the real issue may be the Quota itself. All the other sites I use give you a quota, but it is refreshed periodically, whereas it seems as though here it is permanent. Damian

Perhaps I am just not doing something right. For example, on PLCs.net, when I want to add a picture I.............. Select insert image Select browse Find and select my image Hit upload and I'm done Here I have to leave the post I am in the process of generating to go to the gallery. Then I have to find my personal Gallery. Then I have to hit upload. Then I have to hit browse. Then I have to find and select my file. Then I have to hit review and publish. Then I have to type in some sort of name and description. Then I have to hit Finish and Publish Then I have to go hunt down that graphic in my gallery. Then I have to select "Options" Then I have to select "Share Links" Then I have to copy the image link to my clipboard. Then I have to return to my original post Then I have to select "Insert Image" Then I have to paste the image link. Please tell me I'm just doing it wrong and that there is a kinder, simpler way. At least now I can reference this post when I need to remember how to do it.

Okay

I had issues a few days ago getting Visilogic to update the OS in a V350 using a direct ethernet connection. This connection was via a crossover cable between my PC's LAN and the Ethernet port of the V350. I then added a swtich in between the PC and the PLC and was then able to complete the firmware update. What is happening is with a direct connection the software does a reset of the PLC prior to the update. When this happens the PLC reboots and the LAN detects the loss of a physical connection. Once this happens, Visilogic interprets this as a loss of communication and aborts the update. With the swtich in between, even while the PLC reboots the physical connection between the PC and the switch is maintained. Therefore Visilogic does not sense a disconnection and does not abort the process. Can the OS update code be fixed such that it can "ride through" disconnection caused during a reboot when you have a direct PC to PLC connection? It is not convenient to carry around a switch every place I go and an OS update takes forever over the serial connection. I quite often have systems with a direct connection of the Ethernet between the PLC and slave device so there is not always a switch or a free port on a switch with which to plug into.

The biggest pitfall many folks have when trying to understand ladder is viewing it as a circuit diagram or a relay logic simulator. Using this form of understanding will always lead to wrong conclusions. Ladder is simply a method of graphiically laying out instructions. It is meant to be intuitive for those not familiar with text based programming codes. There are instruction that "test", "operate", and some function blocks that may do a little of both. It used to be common that instructions that performed "operations" always had to be at the end of a rung, but many have adopted series execution over the years. Like everything else it all boils down to knowing the rules of the game the compiler follows. As Joe points out, Visilogic "scans" the ladder with priority (left to right) and (top to bottom). What you see as contacts and coils are very different from physical devices. Right click on a network you are curious about and select "STL quick view". This is how the PLC interprets your ladder. If you ever have any doubts about how things will execute in a network, reviewing the STL translation will show you exactly how it will process. Unfortunately the compiler for Visilogic breaks from all other PLC ladder interpreters in one very crucial way. All other PLC software will only execute each instruction in a network once and only once everytime that network is processed. Visilogic instead will go back an re-execute your "test" operations for the branches and it does not always do this in a consistent fashion. This little detail has in the past caused me many hours of head scratching and grief until I finally studied the STL and realized what was going on. Strictly speaking the compiler should be "stacking" these conditions and buffering the evaluations as opposed to re-testing them but at this stage it is what it is. The best way to deal with this is to keep your networks as short and to the point as possible and to avoid networks that both "test" and "operate" on the same memory value. One thing you will also notice with instructions such as "Energise Coils" and "TD Timer Coils" is they ALWAYS execute if that network is scanned regardless of the ladder conditions directly preceding them. This makes them special in this sense since virtually all other instructions will not not execute at all unless the rung conditions preceding them evaluate to true. This is the key to understanding the difference between a regular "Energize" coil as opposed to "Set" and "Reset" coils. The former always executes regardless of rung condtions wheareas the latter ONLY exectues if ALL preceding condition evaluate in a true fashion. As an exercise regarding your Timer question, create two separate rungs. In one rung use one normally open contact to source two separate times in series. In the next rung, using all the same values, put the two timers in parallel as opposed to series. Look at the STL for both compilations. Do you see any difference?

Is it just me, or does every one else find the process of adding images to their posts unintuitive, cumbersome, confusing, and to a certain degree such a pain that you become reluctant to even bother? It seems like every time I have to post an image it take me 5+ minutes to figure it all out again. You have to go through a series of windows and jump through several hoops to make it happen. Also Why are .bmp banned? That is practically the most benign file type there is. Are you forcing everyone to use compressed formats?

It appears I have found a new way to crash Visilogic. Not sure what this means, but when powering up Vislogic it gave me this error and then would not display the application. I could see the application was resident in memory using Task Manager. Outiside of Task Manager you would not know it was running. I had to uninstall and reinstall to recover.

Organization of data can be just as important as organization of the program itself. Large programs with no clear data organization are difficult to debug and follow. For everything that is seemingly arbitrary, you can usually figure out some means to treat it in a non-arbitrary fashion in order to add a level of clarity. As an example, I like to buffer all of my inputs and outputs into separate subroutines. If I have physical inputs I0 through I 15 I may buffer them to MB1000 to MB1015. For my physical outputs, O0 through O15 I may choose the "manual" buffer bits as MB2000 to MB2015 and the "auto" buffer bits as MB3000 to MB3015. If I have HMI screens with parameters, I may choose to limit each screen to 10 parameters. I will then use 10 contiguous values in the data area and the order that they are layed out on the screen. Even more important is when you start doing communication. For example with Modbus much of the communication time is lost in the overhead of the "packaging" of the data. If you don't oranize this data so that it is contiguous, you will have to get the data piecemeal with separate instructions. If you group properly you can a larger chuck of that data all with one single read. If you have like functions that require unique data and code, then you can save a lot of time with data organization. For example, say you have 8 PID loops that all control 8 temperature zones in exactly the same way. Assign Zone 1 Data Values MI1100 to MI1149, Zone 2 to MI1200 to MI1249, etc. Now simple write the code for one PID loop in its own subroutine. Debug it and get it running prefect. Once it is perfect, copy that subroutine. Then blow down through each one and simple change the values tby 100. Then, as an added bonus, now you can perform vector copies to tranfer the data for zone 1 to the rest of the zones without having to re-type all that stuff. Just copy MI1100-MI1149 to MI1200-MI1249, etc. Now you have a good starting point for the rest of your loops. Also works great for motion axis. Say Axis 1, 2, 3 ect. Setup all identical and just offset the data area by 100 or so. Then in your communication routine you simply indirectly reference that specific axis data area and keep running it through the same sequence of code as if it were a user defined function block.

Count me in now as well for having a request for Bacnet support. I see Joe also posed a question about it on the old forum. Has anyone got this working natively yet?

We first need to determine if you are using RS232 or RS485. What are your jumper setting for the V350 port?

It is pretty typical to reduce the frequency you "test" for communication to an unresponsive slave. You need to build in a means to record the condition of each device. If you are continuosly polling anyhow, the re-tries might as well be set to a minimum. You'll get it the next time around anyway. The timeouts are normally set way too conservatively. Keep decreasing it until you find the point where things start to break down. Then double it. You will find you are still vastly faster yet with a good margin. Of course your baud will affect this as well.

It won't affect the set frequency selected on the controller. Generally you will want your PWM frequency to be appreciably slower than the oscillating frequency of the power you are switching. I would not use the hardware HSO for this. I get the impression you are trying to sychronize your switching with the generators cycle, which Is probably beyond the capability of the control. I would recommend you use a Zero-Cross phase angle SCR style swtiching device controlled with an analog signal such as 4-20mA. Then just have the PID block source your analog output as opposed to PWM. You will get much more stable operation. Especially if you get an SCR with a linear input to power relationship.

If you are using the PWM function block with an output then you should not be setting up that ouput in the hardware config as an HSO. The PWM block is meant to modulate a single ouput on and off at the selected cycle time and duty. If you want the hardware HSO to be cotnrolled by your PID output then all you need to do is link your PID output to your HSO "duty cycle" operand and just select an appropriate frequency.

Hi Joe, only issue I see with your concerns about screw dimensions is that he increased the speed by simply doubling the number of screws used. Thus, at the same rotation speed and all other things being equal it should have picked up the 8 screws just as well as it should have picked up the 4 screws from an individual timing standpoint. If I understand him correctly he didn't change the RPMs, just the number of screws per rev. Hjalli, where are you reading the input? Are you looking at the raw value or scaled value? When you say it "stops counting" are you saying it pegs at 230 or drops to 0?

@ Dahnuguy The Red Lion Data Stations as well as their HMIs can serve as protocol converters. I have used a small HMI of theirs on occassion just to bridge communication. @ Djeanry Are you using FB100? What CPU are you using an what is the physical connection you have? What version of Step 7 are you working with? Are you using a CP343-1?

I have noticed in the past if the version of the OS does not match well with that era of Software build you can get strange anamolies. Don't expect the software to complain, it won't. If you think about it, the new V570 units are probably shipping with an OS suitable more for V9.3 or V9.4 Visilogic. So when using a more current OS with the older software, there are many new features in the OS that the software is not aware of. If you look in the version changes document you will see that they have changed/fixed some things in the CAN programming that I am sure correspond with OS changes. These changes may have affected the compatibily of V8.6 with the new OS.