First machine with Entivity

Just got our first machine with Entivity. I was just wondering should I get the software to support this machine. Don't know much about this system I know it use's function blocks or a flow program.
I haven't got the print out of the program yet. Can I get enough information out of it to know what is going on and how the machine works?

Wondering if any one else is running entivity and how they support it or any other helpful tip's on this system.

I have a single OEM machine using Entivity, it's definately a "beast" (well at least in our application). There are 5 plc projects and 1 pc project controlling this system definatly over-engineered...but I'm going off-topic....

I recommend getting the software, a hard copy of the program will be useless especially if you have multiple plcs in the system like in my case. The manual is very helpful as well.

I've got a pretty good grasp of the flow-chart style of programming, but you have to immerse yourself in it to really grasp everything that is going on, and how it is interacting with different sub systems. There is a learning curve (espcially if no comments are used, and tagnames aren't consistant.)

Could someone give me the "in a nutshell version" of Entivity. I remember discussing it with an Integrator and "Steeple Chase" comes to mind. I don't remember much about that discussion...For some reason I can't seem to get anything good out of Google (a first...)

btw, I like your name magicsmoke.

magicsmoke said:

Just got our first machine with Entivity. I was just wondering should I get the software to support this machine. Don't know much about this system I know it use's function blocks or a flow program.
I haven't got the print out of the program yet. Can I get enough information out of it to know what is going on and how the machine works?

Wondering if any one else is running entivity and how they support it or any other helpful tip's on this system.

Click to expand...

It is based off of Microsoft Visio flowcharts.

So you have "decision" blocks which equate to --| |-- or --|/|--

"Control" blocks which equate to a coil, "calculation" blocks, which allow you to do math..... it reads top to bottom just like any flow chart.

 

Switch 1 = On

          /\              ____________________

         /  \ Y _________|Turn on: GreenLight |

         \  /            |____________________| 

          \/

           |N

           |

           |

    _______|__________

   |Turn On: RedLight |

   |__________________|

           |

           |

           |

      _____|_________________

     |Reset Timer: AlarmDelay| 

     |_______________________|

 

Crude example, but I'm impressed

Oh, it's actually no longer called Entivity, it is now called "Think & Do Studio" Phoinex Contact now owns it, but it is used with AD winPLC cpus as well as any PC for PC based control.

http://web1.automationdirect.com/static/specs/tndstudio.pdf

Both your PLC/PC logic and your HMI are created in one software program which is pretty convienent as well.

Originally posted by surferb:

I remember discussing it with an Integrator and "Steeple Chase" comes to mind.

Click to expand...

Steeplechase was it's own company at one time and made a product calleed 'VLC'. I don't remember a whole lot about it. It was a flowchart type system on a macro level but the blocks contained more detailed code. It had it's own editor. Steeplechase decided they didn't like the whole Windows realtime extention thing. So they used someones realtime operating system and ran Windows NT as a call from that OS.

As you can imagine, this was a pretty touchy system. NT really didn't like playing second fiddle. I saw many a case where the PC with VLC loaded on it would go blue screen and the machine would keep running along happily. The problem was the HMI was also dead (which ran on the same PC) and there was no way to get it back without rebooting the computer. Now THAT would kill VLC.

At some point Entivity, which already had Think'n'Do, bought out Steeplechase. For a while they sold both products. The Think'n'Do logic engine uses the more popular realtime extension method. I looked at Think'n'Do briefly a while ago but never really got into it.

Keith

I've worked with think'n'do quite extensively. Met with the original programmers when it first came out and yes its been through several owners since then.
The same software is used to program the winPLC or run on a PC as an HMI/control package.
Its relatively easy to program , main thing to remember is all outputs are latched, you have to turn them on AND off.
The large array capabilities are handy in certain applications but other than that it is a great idea that just never really reached its potential.
The scan times are a little slow in the win PLC which is where steeple chase came in with extremely fast scan times for very high speed applications.
Bottom line is if you think you need to get into the program you will need the software or have me come up and take care of it

Entivity has been purchased by Phoenix Contact.

I have done one project in Steeplechase VLC using a Phoenix Contact ILC350/VLC controller attached to an HMI and 4 remote drops over Modbus/TCP.

Like any different system, as mentioned, you have to get your head around the philosophy of the programming language to make things work.

Some here will say "run & hide" whenever they hear flow chart programming. I wonder if they have had training on the system or have tried to stumble through it alone because they think because they know one way of programming they know them all.

I would HIGHLY recommend training on the software whether Think & Do or Steeplechase/VLC. This is really a good idea for almost anything, not just Entivity products.

You can find info here:
http://www.phoenixcon.com/software/

<disclaimer - I work for a Phoenix Contact distributor>

There are two products.

One is Steeplechase VLC and the other is Thinking. I helped a customer with a big project.
ftp://ftp.deltacompsys.com/public/PDF/Tamglass%23101.pdf
What wasn't mentioned is that I wrote most of the program. They just wrote the operator interface. The system could support up to 128 axes so I made the system multitasking where each axis got its own chart or program. However, each chart made a call to a common subroutines with the axis number for a parameter and that was used to index into arrays of data where each element in the array belong to an axis. This was very efficient and fast and not near as much code as you may think. There were a few other tasks for handling all the discrete I/O. There were also some temperature PID chars or tasks which were written by the Tamglass engineers. All together there were between 130 and 135 tasks.

What I didn't like was the editor. Wiring up the blocks seem to take way too much time. I would have prefered a cruder and simpler way of stringing the blocks together. I would have prefered that I wrote the code in text and it display as a flow chart in a way one can enter Rockwell ladder in text.

Over all it worked extremely well but as pointed out above, it takes a different way of thinking.

Thanks for the replays.

I just found out that we are getting 4 more machine from the same OEM with Entivity. So I should find out if it Steeplechase or Think & Do and get some training and possible the software. Now I have to just convince my boss to send me to Ann Arbor,MI for training. Since it doesn't look like Phoenix Contact has any where else for traning.

And now for the other shoe...

I have (had) two Steeplechase-based machines, first on NT, then on XP. We rebuilt them ourselves to upgrade the OS and hardware. I programmed in flow chart extensively, and did attend the training.

There are multiple levels of wrong-ness with these systems:

1. Obsolescence. The motion cards we used in these systems were obsolete a year after we bought them. Since it's a 12-axis system, it's not so simple to replace them with anything else. We treat them like they were made of platinum - or maybe plutonium.

2. Software incompatibilities. Never, ever, EVER upgrade the OS the machine shipped with. When these were on our network, security "fixes" pushed from our corporate site KO'd them twice. Not suprisingly, we had to remove them from the network, not only the prevent the knock-outs, but because without the fixes, they turned into virus farms in short order.

Not only that, but if you do get one of their famously cryptic error messages, good luck with that - the VLC guys will blame the drivers, the drivers will blame the OS, and Microsoft will simply ignore you because, hey dude, they're Microsoft.

I should point out that you don't run into this issue with Beckhoff products. Since they make the units stem-to-stern, they take all responsibility for it's behavior when component pieces won't play nice. And no, I don't work for Beckhoff.

3. Assorted gotchas. Be really careful with the "overwrite retentive memory" switch. Depending on the version, you had to check it to prevent overwriting, or check it to allow overwriting. Either was horribly destructive.

Also, remember to compile your HMI, your flows, then the project, in the correct order (my original notes had something like 10 steps to follow) or your HMI will look at the wrong project, or your project will display the wrong HMI, etc.

4. Black-box add-ins. We used Sherlock for vision, VLC for controls, and to move the vision data from sherlock to VLC, our OEM had this little wedge program written in VB, all their own. It's so odd how, under XP, this little thing like to use 99% of the processor's activity...

Eventually, you may find yourself doing what I did, finally after 6 years - rip the SOB out of there, replace it with a pair of Trio 206x and Unitronics V280's for the front end, and throw that PC in the dumpster. Will go down as one of the most satisfying days of my life.

Good luck - you're going to need alot of it.

TM

The shoe on the other foot......

Disclaimer: This posting is from the Marketing Manager responsible for the Steeplechase VLC, Think & Do software products and other Automation solutions from Phoenix Contact. Phoenix Contact purchased Entivity, Inc (and the Steeplechase VLC and Think & Do software products) to create a USA based software resource with products and control software applications based on PC based technologies.

Obviously, it looks suspect that my first posting on this forum is to respond to a criticism of one of our software products. However, I thought the members here might appreciate a candid response of these observations from inside our company. I have attempted to be as honest and “non-salesy” as possible in my comments. Phoenix Contact is currently investing heavily in both Steeplechase VLC and Think & Do. We are committed to providing software solutions that exceed our customers expectations. The only way we will do this is by hearing both the good and the bad experiences from those using our products. As such, I welcome any feedback, comments, questions or recommendations about future functionalities that we might provide with our software and automation products.

Magicsmoke, Paully’s5.0 and alanMICS - Thanks for your business. Please let me (or your local Phoenix Contact salesperson/distributor or tech support) know if we can ever be of any assistance.

And Magicsmoke, I can definitely recommend you attend our training class in Ann Arbor, MI. (I typically say pick a warm month, but being in MN you're likely used to the cold) We do have a lot of product training for general products in our facilities in Harrisburg and Houston (and at regional seminars), but we only do the main training for VLC/T&D in Ann Arbor. The main reason for this is that it is where the developers are located. Some of them have been with Steeplechase since the very beginning over a decade ago, and are still located there. I tend to think having them in the same facility, and at the occasional access of the training department while teaching a customer training, says something positive about the very open dialogues we hope to maintain with our customers, from the training room, to tech support and over to the guys writing the source code of the next generation product in the room next door. (That is something that definitely not all software companies can say anymore……)

Tim - You make some interesting observations. In response to your points:

1. Obsolescence. The motion cards we used in these systems were obsolete a year after we bought them. Since it's a 12-axis system, it's not so simple to replace them with anything else. We treat them like they were made of platinum - or maybe plutonium.

Steeplechase was one of the original PC-based controls company. At that time, the company was an independent software company with no hardware affiliations. The whole concept of PC-based control and open automation was to integrate “best in class” of hardware and software to create control solutions that were either not possible or were too cost prohibitive with PLC architecture. As such, Steeplechase created drivers that would communicate with the hardware of various 3rd party vendors. Hardware obsolescence is a problem in both the PC-based control world as well as the PLC world. However, because improvements and changes in PC hardware typically occur several orders of magnitude faster than in PLC hardware, obsolescence of 3rd party hardware also takes place much faster. This is something that is out the control of an independent software company.

Now that the Steeplechase VLC product is part of Phoenix Contact, we are and will continue to provide more complete Phoenix Contact solutions.

Our experience in the open automation world is that 'the component with the most mystery always gets the blame' and the component with the most mystery is always the software.

2. Software incompatibilities. Never, ever, EVER upgrade the OS the machine shipped with. When these were on our network, security "fixes" pushed from our corporate site KO'd them twice. Not suprisingly, we had to remove them from the network, not only the prevent the knock-outs, but because without the fixes, they turned into virus farms in short order.

One of the differentiating features in the underlying architecture of the Steeplechase VLC product, is a real-time, deterministic operating system called Intime. This RTOS was developed by Intel in the 1970's and exists in millions of embedded controllers. When running on a PC, it provides a segmented memory space for the control logic and ensures deterministic performance regardless of what Windows is doing. It also provides protection from what is known as the Windows “blue screen of death” fault, which was very prevalent in the Windows NT 4.0 days.

During the NT 4.0 days, the Intime RTOS would replace the hardware abstraction layer (hal.dll) with it's own. Subsequent MS Windows OS updates would replace the Intime hal.dll and this would indeed pretty much render the PC unusable. Fortunately, the Intime product has evolved to the point where replacing the hardware abstraction layer is no longer necessary.


Not only that, but if you do get one of their famously cryptic error messages, good luck with that - the VLC guys will blame the drivers, the drivers will blame the OS, and Microsoft will simply ignore you because, hey dude, they're Microsoft.

Admittedly, we could do a better job with the errors that come from our I/O drivers. This is something we are working on.

In our defense, we do think that our tech support people are very good at translating the errors and we are always making a conscience effort to improve the error messages. (And again, I do take a note of pride here in that our tech support personnel -on all our products- is not an outsourced call center.)

When you are a company with a PC-based control software product, you find yourself assisting customers with the troubleshooting of not only your own product but everything else that runs on the PC as well. Admittedly, sometimes certain problems are Microsoft related and out of our control. In these situations, we do our best to provide a work around that is satisfactory to the customer.

I should point out that you don't run into this issue with Beckhoff products. Since they make the units stem-to-stern, they take all responsibility for it's behavior when component pieces won't play nice. And no, I don't work for Beckhoff.

Any Beckhoff product that runs in a Windows environment has to face the same issues that every other software supplier faces.

However, I definitely agree with you regarding the customer benefits of “one call to make” vendor support for when components don’t work together as promised. With the acquisition of Entivity, Phoenix Contact is committed to taking responsibility for all aspects of a Steeplechase VLC/Phoenix Contact solution. Obviously, we cannot retroactively modify or take responsibility for legacy installations with third party vendor equipment, but I do believe our latest introductions of VLC-based embedded products on Phoenix Contact manufactured hardware to be very good examples of this philosophy.

(--continued next post--)

(continued from previous post)

3. Assorted gotchas. Be really careful with the "overwrite retentive memory" switch. Depending on the version, you had to check it to prevent overwriting, or check it to allow overwriting. Either was horribly destructive.

Also, remember to compile your HMI, your flows, then the project, in the correct order (my original notes had something like 10 steps to follow) or your HMI will look at the wrong project, or your project will display the wrong HMI, etc.

The Steeplechase product was always bundled with a 3rd party HMI product. In the early days it was the FIX from Intellution. The product is currently bundled with Citect and Iconics MachineWorx. The problem that you are refering to was with the Citect product and was a characteristic of Citect and not of the VLC. This is not an issue with Iconics MachineWorx or any other HMI product with modern day OPC client capability. Look for tightly integrated Phoenix Contact HMI solutions in the future.

4. Black-box add-ins. We used Sherlock for vision, VLC for controls, and to move the vision data from sherlock to VLC, our OEM had this little wedge program written in VB, all their own. It's so odd how, under XP, this little thing like to use 99% of the processor's activity...

Yes, bad things can happen in Windows; poorly written drivers, software applications that are memory hogs or CPU hogs. Fortunately, the VLC control application is protected from these situations because it is running in it's own RTOS. Amazing new things are now possible with the advent of multi-core CPU's where your control application scan run in one core and your HMI or SQL appplication can run in another core. This would mean that an application using all the the CPU cycles in one core would have no effect on the performance of an application running in another core. Go to www.tenasys.com for more details.

Respectfully Submitted,

Greg Dixson
Product Marketing Manager
PhoenixContact, USA
Harrisburg, PA

PhoenixContact, does Think n Do have a Ethernet driver yet? The last time one of our customers used Think n Do they had to use Profibus DP. The Tamglass project used an SST Profibus DP card to communicate with all of our controllers. Recent projects have been with VLC and Ethernet. The VLC system has a Modbus driver which appears to work quite well but Modbus/TCP is very limited in the address space it can access. Modbus/TCP also is very limited in the packet size. Finally Modbus/TCP doesn't support UDP which is better for I/O updates. It would be nice to have a Ethernet/IP driver as it is better than Modbus/TCP in many ways.

TimothyMoulder, you chose the wrong motion controller. I don't see how you can blame the the motion controller you chose becoming obsolete on the VLC. PC hardware becomes obsolete as as the PC change. It seems there is a newer faster PC bus every two or three years. Tamglass can still get the same motion controller that we sold 8 years ago. This is possible because the motion controllers are connect using Profibus DP which is a standard that will not change every couple of years. It is best if the I/O does done over Ethernet or Profibus DP. This way the I/O or motion controllers don't need to be changed as the PCs change. Our products work with both Think'n'Do and VLC and have for years.

Timothy - I like how you put things.

Wow, Phoenix - that was: long, a bit "salesy", and very informative. I think user responses were pretty positive to your products. I hope you don't find this offensive, but one take away for me is that tracking your history is too confusing (Entivity, Think & Do Studio, VLC, Phoinex Contact and the various hardware, software, and operating systems). This post will be my reference if I ever have a question.

You might want to be careful there - multiple CPU cores aren't that magical. Think of all the shared resources they are depending on. And a crappy driver will hose you. You still need a solid scheduler, which is probably present under your RTOS. You do get obvious advantages such as reducing the context switching (expensive) that a single CPU would have to do often.

This would mean that an application using all the the CPU cycles in one core would have no effect on the performance of an application running in another core.

Oh yeah - and ask Pete if you have a motion controller question ;-)