Flex727

Only if you "Download All & Burn". There's no reason to waste time with that process until the software is final.

Did you try pulling the battery?

Check the example projects that came with your VisiLogic installation for the proper way to set up this type of communications.

I always run the I/O module power on the same circuit as the PLC. Why would you power down the I/O and keep the PLC running? That's just asking for problems. The way we do things: K1 Power relay: Powers entire cabinet, shuts off when EMO pressed. PLC and I/O modules are on K1 power. K2 Power Relay: Powers output relays and other misc. Turns off when an interlock alarm occurs. When it is shut off everything powers down except PLC & PLC I/O modules. It can also be turned off and on from the PLC HMI.

Can you clarify what you mean by this? It might help if you explained what it is you're trying to do.

I see no reason to use Float for any of this. Just multiply the numbers, use MLs for the result, divide to get the precision you want, and keep track of where the decimal is for displaying.

The most common reasons for failure of a coil to be activated are: in a subroutine that is not being called, or duplicated elsewhere in the program. You've apparently addressed those. Another possible cause is that the program you are using in VisiLogic is not identical to the program in the PLC. VisiLogic will not warn you of that problem. A troubleshooting technique I like to use is to place an MI Increment function just after the coil. Whether or not the MI increments will help lead you to the source of the problem.

Normal integer Numeric input handles this easily - no need for floating point. The resulting (MI) number input will be 10x the desired value, but you can handle that in ladder with the proper math (or the proper values in the linearization function block).

I came from a computer programming background as well and I think that was probably the hardest thing for me - unlearning ingrained habits from that world. PLC ladder logic is fundamentally different and failing to wrap one's head around that is probably the most common problem I see with new PLC programmers. Joe Tauser's State Machine example shows the proper way to handle situations where you are stepping through a process sequentially and want to avoid code until it's time for it. It definitely opened my eyes some years ago when he first posted it here.

I'm offering advice based on my experience. You're free to accept or ignore it as you choose. My way of doing things is my way, not the only way. My philosophy is to never use GoTos or conditional triggers for subroutines. I find that it's a better way, but it's not the only way. In my opinion, subroutines in ladder logic should be used differently than subroutines in normal computer programming. A normal computer program has a beginning and an end with subroutines for specialized tasks. In ladder logic, you have continuous execution of all code in a never-ending loop. Going off to execute a subroutine for a specialized task, or using GoTos, risks triggering the Watchdog Timer, which is a major fail for the programmer. I use the Main Routine only for Power-Ups and subroutine calls. Then all the code is broken up in logical chunks for easy understanding and readability into subroutines.

Here is what the top part of my primary desktop looks like. I position the Version Swapper icon under the VisiLogic version that is currently active and swap as needed. Why so many versions? I refuse to update the firmware at a customer site if the installation is working. "If it ain't broke, don't fix it." Version Swapper works great and reliably on my Windows 7 system.

Please allow me to repeat what I said above: Write your code with this in mind and you'll have much more success with PLC ladder logic, now and in the future.

There is additional filtration available via ladder. Look under the FB's drop-down menu.

You are trying to program like you would a computer with some other language, not program a PLC with ladder logic. PLC ladder logic should be organized completely differently. Every rung of every subroutine should be evaluated on every scan. You probably should be using a State Machine instead of what you're trying to do. Our resident genius, @Joe Tauser, has written an example program to help educate us on this terrific technique to handle the type of situation you are trying to deal with. Looking at your edit, it appears you might be headed in the direction of a State Machine, which is great. Look at Joe's example program and see if it helps you.

If ladder rung #1 is supposed to be a standard latch circuit, it's wrong - MB 2 should be MB 4. I think conditional subroutine calls are very poor programming practice. You have to be extremely careful not to leave coils hanging in limbo when the subroutine stops being called. With PLC ladder logic, the next subroutine is normally called when the previous subroutine is finished - and not before. You don't need a bunch of code to create that situation, as you seem to be doing here.

Yes, there is a GoTo in Unitronics Ladder Logic, but it should be avoided. It is poor programming practice in 99.9% of circumstances. There are far better ways to execute only the rungs you want executed. My philosophy is to work backwards from outputs or coils to inputs or contacts. Determine every circumstance that should turn that output or coil on and write that logic. When that is correctly done, there is no need to skip rungs because they will not activate the output or coil automatically. A simple way of accomplishing this is to assign a coil to turn on when a>=b, then place the inverted contact of that coil in front of the logic you want skipped.

It seems that way too many programmers (especially in the beginning) fail to recognize what the ladder rungs are in ladder logic. The screen is not just a blank slate to write the logic willy-nilly. The purpose of the rungs and separating logic threads is that the compiler will create machine code that tells the PLC to fully evaluate a single ladder rung before moving on to the next rung. When you have two logic threads with dependency between them and place them both in the same ladder rung, the programmer has lost control over order of execution. When in separate rungs, the programmer knows the first rung will be fully evaluated before starting on the next.

You don't need to do Download All & Burn until you're ready to place the machine into service. During program development and troubleshooting, just do a simple Download. Download All & Burn wastes a LOT of time unnecessarily.

I think he said it backwards - do not combine networks in a single ladder rung. The first picture shows two independent networks, or logic strings in a single ladder rung. NEVER DO THAT. The second picture shows the the logic broken up into two separate ladder rungs properly. I created the examples in VisiLogic to show more clearly. Rung 1 shows how NOT to do it. Rungs 2 & 3 show the correct way:

The first two don't look fine. The compare is false, yet the coil shows as true (they're in red). Do a find on each of the coils (MB 16, 17, & 41) and confirm they are not duplicated elsewhere. Also, confirm the subroutine with the compares is being called in the Main Routine.

How many HMI screens do you have in the program? Probably the easiest thing to do is to open the V430 project, go to the first HMI screen, Ctrl-A, Ctrl-C, open the Samba project, go to the first HMI screen, Ctrl-V. Save & repeat for each screen.

I would do it this way: ML 0 would be your total accumulated hours. You could add a reset pushbutton that zeroes both ML 0 & MI 0 when the blasting wheel is replaced.

Yes, but I don't have a deep enough understanding of the compiler to know the result. With SB 1 there, I know exactly what the compiler will do. Like I said, your expression will most likely work perfectly, it's just poor practice since more complex expressions can get you in trouble. Placing a line there instead of SB 1 will also most certainly work perfectly - I just consider that also to be poor practice, though others may not agree. By the way, even a technically legal logic thread can get you in trouble with order of execution. You should always break the logic up into the smallest pieces as practical to place in separate rungs.

I also sometimes (but rarely) like to combine multiple pieces of very simple logic together, as you are doing above. Here is the way I do it: This will compile as you would expect, but this is purely an organizational thing for easier readability to the programmer.