I've run into a situation where Keyence doesn't have a windows 7 (64 bit) compatible software that can program their original KV series of brick PLCs. They have a solution for their newer style "visual KV" series but we have many of the older ones to support indefinitely. The version of the software we have used with winXP was "Ladder Builder 1.50" (circa 1996-1997).
Unfortunately this software has trouble with a virtual machine "shared folders" that are implemented via network shares visible to virtual XP (I've tried both VirtualBox and WinXP mode). Mapping "real" network drives in the virtual machine works but this is not ideal for us for several reasons outside the scope of this discussion.
My question is does anyone know what the latest version of Keyence software is that supports the original Keyence KVs? (KV10, KV16, KV24, KV40). It doesn't have to work with Win7 64bit, just hopefully handle windows networked filesystems better.
Ken Emmons Jr.
QA Technology Company, Inc.
110 Towle Farm Road
Hampton, NH, 03842
I am supporting a large base of a customer's KV24s for several years now on a Win 7 64 bit notebook. I am using the Keyence KV Ladder Builder software version 1.51.
I installed VMware Player 3.1.5 and Windows XP Pro. A real version of XP is required off a CD not the XP that comes with Win 7.
I can upload and download to the KV24 through the USB ports using an inexpensive USB to serial device.
By the way, VMware Player is free.
Automation & Controls Engineering, Ltd.
Minneapolis MN 55364 USA
Thank you for your reply. I did manage to get 1.50 working with virtual PC/XP mode but I have to use a virtual network card to log into our file server which exposes the VM guest to our network and adds network login complexity.
What we would like to do is have a generic VM guest that has the software installed and uses the shared folders feature to get at local and network drives on the host. In this sense the VM guest can write to the host's networked and local disks with the *host* user's permissions. So the guest VM OS isn't even connected to our network so to speak.
The problem is that version 1.5 of ladder builder cannot read the virtual "shared folders" network mapped drives when you go to File-Open or save for that matter. Did you manage to get this working with VMWare, or are you doing something like copying in the Keyence projects, editing them, and then copying them back to the source? All of our files are stored on the network file server so that they get tape backed up and so others can access them, etc.
Thanks for the tip Robert, I will try VMware again since I have my own XP image on one of my other machines. I did try Virtual Box and it had the same problem as virtual PC. I thought its shared folders were network drives, but maybe they handled them better than microsoft's virtual PC and as such is compatible with this ancient software. That would be good in a way since I think virtual PC is inferior to VMware and it would be an excuse to use it instead.
An alternative I might try is to write a file copy program that automates the process or use a central version control scheme which will accomplish the same thing (with just a bit more complexity).
NEVER use Virtual PC shared folders for anything important! There is a known issue that can lead to data loss or corruption, and I've been bitten by it myself so I can attest to it.
If you want to do something more complicated than simply dragging the files in and out of the VM to the host machine desktop or folders, you MUST set up networking between the guest OS and the host OS or whomever you want to share files with.
To Steve Meyers: Can you elaborate a little? I've done a search on my web search of choice and didn't come up with anything related to data corruption with windows 7 virtual PC and XP mode shared folders. This is disconcerting to say the least. Was this with Virtual PC only, or does VMware / virtualbox suffer the same way?
I just wrote a program to copy the Keyence files to the c:\temp of the virtual machine guest, fire up the editor software, and then copy the files back when the editor has finished. It works well.
Another program I'm using the virtual PC for is to simply download a program file to a serial device (i.e. read only). Although it does build temporary intermediate files for the download that I don't care about.
A third program I haven't tested yet accesses many files and does some "compiling" and serial download of data to a robot (It is conceivable I can copy-in/Copy-out these projects as well).
> To Steve Meyers: Can you elaborate a little? I've done a search on my web
> search of choice and didn't come up with anything related to data corruption with
> windows 7 virtual PC and XP mode shared folders. This is disconcerting to say
> the least. Was this with Virtual PC only, or does VMware / virtualbox suffer the same way?
Haven't run virtualization in Win 7 yet. I'm talking about standalone Virtual PC under a Win XP host (but depending on how much of the code in the new built-in mode is inherited from VPC, it might affect that too for all I know). And yes, only Virtual PC, not VMWare or other systems, and only Shared Folders, not running as a virtual network with shares.
Not certain that this relates to your issue or not but it does relate to a Windows 7 issue that gives us some grief and may shed some light on your conversations with Steve Meyers.
Windows 7 has a new "feature" called "compatibility files" that you should be aware of. This is not "compatibility mode". It is "Compatibility Files"!
IF you have programs that store data in a "Path" that is under "Program Files" be aware that what you "save" is not actually saved in that path. Instead, a copy is made and stored in an obscure path "somewhere" on your hard drive. You are never notified that this is happening. Later, when you "open" the file, the copy will be opened instead and you will again not be notified that this is happening!
Just be aware that if you copy what you think are current files that you are actually coping the old, non updated files. It can get you into serious trouble!