I'll answer your questions in reverse order.
Do I load multiple projects on the PLC then run them when required....
The PLC can only have one program loaded at a time.
... or load a new project based on the recipes conditions?
No. Your VB program will not "know how" to download a program. That's what the Versapro software is for. While GE has released some of the protocols for talking to the data memory space of the PLC, the program space is closed, proprietary and off-limits.
I would like some advise on how my VB language sends instructions to the PLC ie, 9030 or 9070. I am familiar with Versapro ans LM90 to program the PLC but I need to know what is the protocol for instructing the PLC from my PC application
What you will be doing is sending numbers/bits to the PLC, and reading them back. The communication link is likely to be slow (compared to PLC scan), so you'll want to let the PLC handle as much of the decision making as possible.
As far as handling multiple recipes, there are several techniques:
1) The Sequentia S-88 approach: The process will be divided into small, self-contained operations called 'phases'. I've tried to find a clear, plain-English definition (as opposed to ISA's definition) of a phase, but have so far been unsuccessful. Tyupical phases are "Get material X from this spot to that spot", or "Heat the tank to this ramp profile". There is usually a setpoint associated with a phase (there may be more than one, such as agitate for this TIME at this SPEED ramping at this RATE. The TIME is the key one - it lets us know when the phase is done)
Your VB app will then send the PLC a bunch of numbers in a predined location (e.g. TIME, SPEED, RATE) and tell the phase to run (a bit in a memory register). The phase will do it's thing, and your VB app will monitor a bit and wait for it to say "I'm done - what's next?). Your app then launches one or more phases.
By modularizing the process, you give great flexiblity to recipes
.
.
2) PLC-driven batch engine: The same basic approach, but the engine that determines the order is in the PLC - the PC just downloads all the setpoints at once, and then sets the GO bit. The PLC takes over from there.
The nice thing about this approach is that the PLC is a lot less likely to hang (or lose comms with the PLC) than the PC. Once the batch is running, it keeps running, pausing only for pre-defined operator interaction.
You don't have to limit it just the setpoints. If the order of the phases changes in a recipe, that can be downloaded too.
.
.
3) Multiple Recipes in the PLC: PLCs have subroutines, which can be called (or not) as programming requires. You could create a subroutine per recipe, and then pass the PLC a number, and the PLC will be programmed to only run that subroutine, and not others.
4) Repicpe specific actions. Variations on all of the above. You pass the PLC the recipe number (or set of numbers). Various sections of PLC code are written "If RecipeNo = 5, do this, if RecipeNo = 6, do that, If RecipeNo <> 5 and <>6, do something else.
That's all I can think of off the top of my head. There are many more approaches, I'm sure.
Again, the principle is that the PLC code does not change, but you pass the PLC numbers/bits to enable/disable logic.
.
.
I have plenty of experience with VB/C and have written complete appications for high speed robotic systems. My problem is they want me to use GE Fanuc PLC control on a system instead of the NIDAQ or GPIB cards I am familiar with.
I have no idea even what NIDAQ or GPIB cards are, so we may have some serious communication gaps.
One of the hardest concepts for a VB programmer to understand when dealing with PLCs is the concept of SCAN. The PLC program does not start and stop like a VB program. It's the Energizer Bunny - it keeps going and going and going.... In VB, you typically open a file, crunch some numbers, load them into the file, close the file, and quit. The PLC program opens the file (reads Input modules) runs ALL the logic (unless specifically told not to), write to the file (writes to the Output modules), and then does the whole thing over again.
When you code, you need to mentally keep track of what's going to happen on the next scan to logic ABOVE the rung you've writen (which won't be affected THIS scan).
If you haven't yet, order Phil's excellent book (blatant plug), and go through the online tutorial. PLC programming is different from VB or C coding.
Hi,
I am new to this site, it looks very helpful.
Welcome.
Thanks, we like it.