Jump to content

Recommended Posts

Posted

I have resorted to running Visilogic in an XP virtual machine because it is simply unusable under Windows 7 64 bit.

For anyone else who may also want to run Visilogic within the XP virtual machine built into Win7, after installing you may notice that your Visilogic screens may appear garbled. This is because XP mode defaults to 16 bit color mode.

If you go to the windows properties and attempt to change the screen settings to 32 bit, you will notice that only 16bit shows as available.

You must first go up to tools and select "Disable Integration Features".

Then go back to configuration and you will now find that 32bit color is now an option.

Unfortunately you will not be able to re-enable integration features and retain the 32 bit color mode, but it is not necessary for running Visilogic as long as you are communicating over Ethernet or and USB to Serial converter.

Posted

Hi Damian,

I've been running Visilogic under an XP virtual machine for a year now, under Linux and Win7 hosts:

http://forum.unitron...age__mode__show

I've not had the problem you describe. Are you using vmware or virtualbox?

TM

Hi Tim,

Windows 7 actually has a built in virtual machine, so I am not using VMware or Virtual Box. The attractive part about the built in version is that you get a "free" XP liscense/install whereas VMware and the others require you to install a purchased copy of XP. I have read, and enjoyed your blog on using VMWare, and actually will be giving it a try eventually as it appears to be much easier to back up than the built in Microsoft version.

I am really getting frustrated with the odd behavior of Visilogic under Windows 7 64bit. I am suprised that nobody else has been making noise about it. It would be nice to compare systems with someone who is to help possibly indentify the root cause. Since it works in the VM, I can't justify the expense in time trying to work out the Win7 issue.

Thanks,

Damian

  • External Moderators
Posted

Hi Damian,

I had an experience last week that has some bearing on your situation. It was time to validate a couple of Omron-based machines as part of our pre-relocation inventory. I tried to get online with my linux/xp combo running CX-One, and failed completely. None of the comm drivers would work, serial or usb.

I researched this ad nauseum, and found I was not the first to experience this problem, specifically with CX-One. Apparently Omron was late to the game supporting Win7, and alot of guys tried to VM XP to support their equipment. Omron provided no support for this at all, completely silent in fact. Some guys theorized you had to have Omron's drivers installed in the host, but I'm running Trio and PcanOpen both without any special setup, so unless Omron purposefully set it up that way, I couldn't imagine it.

I tried every configuration I could think of, including making a separate XP service pack 2 VM and hacking the VM config file to simulate a 32-bit version. Still no love from Omron.

In the midst of all of this, Omron began supporting Win7, with a laundry list of caveats, but I finally switched my host OS to Win7 and got CX-One operational. $#$#&&^ the %$^% off, because I had to lose linux to do it, but I also have to support this equipment, so there it is. I hate Omron.

Long story short (I know, too late), the part you should know is that when I moved my usual VM from Linux to Win7, it went off without a hitch. Had to reassign the virtual CD-Rom manually, and reinstalled VMware tools as a precaution, but otherwise, smooth as silk - the main reason I went to a VM scheme in the first place.

Of course, I use VMware Player (free). I've heard good things about the XP client in Win7 Pro, but I'm old enough to remember "Dos Mode" under Win98, and I find myself thinking about the compatability issues people had back then too, running what was essentially a stripped-down DOS VM. Microsoft is doing a better job these days, but virtualization is not their key revenue stream, so I have my doubts about it. And I seriously doubt you could move the instance you are running to another host OS in any way, shape or form.

Best of luck,

TM

Posted

I am really getting frustrated with the odd behavior of Visilogic under Windows 7 64bit. I am suprised that nobody else has been making noise about it. It would be nice to compare systems with someone who is to help possibly indentify the root cause. Since it works in the VM, I can't justify the expense in time trying to work out the Win7 issue.

Hi Damian

I'm running on Windows 7 64bit and had a few crashes with VisiLogic 9.3. Haven't had any trouble with VisiLogic 9.3.1 though, and no slow downs on any version. What anti virus are you using?

Posted

Hi Damian

I'm running on Windows 7 64bit and had a few crashes with VisiLogic 9.3. Haven't had any trouble with VisiLogic 9.3.1 though, and no slow downs on any version. What anti virus are you using?

Thanks for the feedback.

My system is a Dell Precision M6500 with core i7 & 8GB ram, Windows 7 Ultimate 64bit

Also have a SSD, not sure if it is relevant but if it was I wouldn't expect different behavior within the VM.

I am running Kaspersky Internet Security 11.0.1.400. It was the first place I looked when the problem occured. Turning it off had no effect.

The slowness is sporadic, but once it shows up it never just clears up.

It is most noticeable when doing communications related activities, and doing File Save/Open types of things.

It also happens often when selecting different subroutines or HMI screens, or inside the HW configuration.

If I am just building ladder, I rarely see it when I am actually drawing the logic. Only occasionally when I highlight a new network it will go to sleep for a spell.

Posted

Hi Damian,

I had an experience last week that has some bearing on your situation. It was time to validate a couple of Omron-based machines as part of our pre-relocation inventory. I tried to get online with my linux/xp combo running CX-One, and failed completely. None of the comm drivers would work, serial or usb.

I researched this ad nauseum, and found I was not the first to experience this problem, specifically with CX-One. Apparently Omron was late to the game supporting Win7, and alot of guys tried to VM XP to support their equipment. Omron provided no support for this at all, completely silent in fact. Some guys theorized you had to have Omron's drivers installed in the host, but I'm running Trio and PcanOpen both without any special setup, so unless Omron purposefully set it up that way, I couldn't imagine it.

I tried every configuration I could think of, including making a separate XP service pack 2 VM and hacking the VM config file to simulate a 32-bit version. Still no love from Omron.

In the midst of all of this, Omron began supporting Win7, with a laundry list of caveats, but I finally switched my host OS to Win7 and got CX-One operational. $#$#&&^ the %$^% off, because I had to lose linux to do it, but I also have to support this equipment, so there it is. I hate Omron.

Long story short (I know, too late), the part you should know is that when I moved my usual VM from Linux to Win7, it went off without a hitch. Had to reassign the virtual CD-Rom manually, and reinstalled VMware tools as a precaution, but otherwise, smooth as silk - the main reason I went to a VM scheme in the first place.

Of course, I use VMware Player (free). I've heard good things about the XP client in Win7 Pro, but I'm old enough to remember "Dos Mode" under Win98, and I find myself thinking about the compatability issues people had back then too, running what was essentially a stripped-down DOS VM. Microsoft is doing a better job these days, but virtualization is not their key revenue stream, so I have my doubts about it. And I seriously doubt you could move the instance you are running to another host OS in any way, shape or form.

Best of luck,

TM

Hi TM,

The only reason Mircosoft packaged the XP VM in Win 7 was to attenuate peoples fears of backwards compatibilites. So far the only glitches I have not been able to overcome are getting Rockwells activation server to work properly in the VM (I am told it want's to see a client/server setup with the host, but that defeats part of the point of having the VM in the first place), and issues with Rockwells drive server and recognizing the thrid octet of the IP address properly. I look forward to giving VMWare a try, largely because the backup routine for the XP machine in Win7 is not what I would call convenient.

Thanks for all the info. Sorry to hear you had to lose the Linux.

D

Posted

Thanks for the feedback.

My system is a Dell Precision M6500 with core i7 & 8GB ram, Windows 7 Ultimate 64bit

Also have a SSD, not sure if it is relevant but if it was I wouldn't expect different behavior within the VM.

I am running Kaspersky Internet Security 11.0.1.400. It was the first place I looked when the problem occured. Turning it off had no effect.

The slowness is sporadic, but once it shows up it never just clears up.

It is most noticeable when doing communications related activities, and doing File Save/Open types of things.

It also happens often when selecting different subroutines or HMI screens, or inside the HW configuration.

If I am just building ladder, I rarely see it when I am actually drawing the logic. Only occasionally when I highlight a new network it will go to sleep for a spell.

Just FYI, I am running a Lenovo ThinkPad X201, Core i5 M580, 4GB of RAM and a 128GB SSD. Using avast! free anti virus.

I am using VirtualBox on my work server. Linux host and Windows VM guest so we can run our accounting software. VirtualBox works great and it's free. Not a as feature rich as VMware obviously but you can't beat free. Sorry I can't be of more help.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

This site uses cookies. By clicking I accept, you agree to their use.