PanelView 64 bit

We are bidding a job and I saw this in a customer specification:

"FactoryTalkViewME (PanelviewPlus) applications must NOT be developed on computers running a 64-bit operating system unless approved otherwise in writing by OC engineer"

Why would it matter if I'm using a 64 bit computer or a 32 bit computer for the panelviewPlus? Can you even purchase a 32bit computer anymore? I know about VMware, but I'm 99.9% sure we only have 64 bit computers at the office right now.

If anyone has any insight on what the issue would be, please let me know!

FTView had an issues with older versions going between 32 and 64 bit machines. There are tons of threads on the issues and why if you wish to search them. However, with newer versions, its not an issue. I'd be willing to bet you were sent and older spec that hasn't been changed and is no longer and issue.

Helliana said:

FTView had an issues with older versions going between 32 and 64 bit machines. There are tons of threads on the issues and why if you wish to search them. However, with newer versions, its not an issue. I'd be willing to bet you were sent and older spec that hasn't been changed and is no longer and issue.

Click to expand...

That makes sense. The spec does also call out for V20 OR V32 of RSLogix, so maybe the plant is operating a lot of older PLCs & Hardware.

When Rockwell finally released a 64 bit version of FactoryTalk (around v6), it was, as one one would expect, a disaster. They changed database vendors from Watcom to MSSql (if I'm remembering correctly). The result would be that if you edited an application on a 64 bit machine, you then had to jump through some hoops in order to edit it on a 32 bit machine. You basically had to do this:

• Restore export the tag database on the 64 bit machine
• Run it through a conversion utility
• Restore the application on the 32 bit machine
• Import the converted tag database.

Because of this, many people made the policy to only allow 32 bit machines. Our controls department uses 32 bit VM's manly to not trigger issues with our existing customers who still have older equipment.

I don't think this is an issue with more modern versions, it seems like at around v8, a lot of this has been cleaned up. There are still pitfalls around v6.1 and lower though. I'd think these days, spec'ing the version would probably be more important than the OS architecture.

All this weird compatibility nuances causes a lot of grief for us OEM's, where we have machinery out there all the way back to v3.2. We have to know all of these idiosyncrasies. We'll get the calls "Why can't I restore this application", "Why won't this compile", "Why won't it let me make a runtime at this version", "Why does it complain about activex version when I try to restore". It's very frustrating. [/tangent]

Rson said:

That makes sense. The spec does also call out for V20 OR V32 of RSLogix, so maybe the plant is operating a lot of older PLCs & Hardware.

Click to expand...

This specific requirement is probably due to the hardware refresh. 1769-L32E and 1769-L35E Compact Logix controllers, as well as 1756-L5x controllers, can only be flashed as far as v20. Everything newer than that can generally be flashed from v20 all the way up to the most recent version (at the time of writing). A 1769-L35E is not all that old, there are still plenty of places with lots of them around, so it makes sense to say "ok, for the older stuff, it must be on the most modern version it supports. For the newer stuff, we're currently using v32". At the time of writing, the newest version out is v33, so the spec is obviously reasonably up-to-date.

1756-L5X can only go up to V16. 1756-L6X can go to up v20 as can the 1769-L32E and 1769-L35E

Duranthas said:

1756-L5X can only go up to V16. 1756-L6X can go to up v20 as can the 1769-L32E and 1769-L35E

Click to expand...

Right you are, thanks for the correction!