I'm testing Codesys Control Win (64-bit), latest available version, on a Hyper-V virtual machine. The installation of the runtime went smooth, as went the download of the application to the device.
But when scanning for the modules, the following error occurred:
What could be the cause of this. Could this be a network configuration issue?
Reno
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Slave problem?
Reduce slaves, sounds for me like one is connected which has a problem.
So I would start with less and add one by one...till you have the one.
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply. I would assume there is a corrupt module as well, if they wouldn't work on a physical server either. But they are all operational without packet loss on a physical server.
So it appears to be something with the virtual server. I have too little experience with how eeprom works and what could be blocking/preventing access to the slaves.
The weird thing is, the scan is able to detect the slaves. But unable to assign addresses.
Have you got any idea what could be causing this, given the situation determined above?
Reno
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
one remark,
is really WinPcap installed on this system?
Nmap does not work. ( Will be fixed, but do not know when)
So please check if WinPCap is installléd on this system.
Could you add the plc log?
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Profinet driver needs to send and receive raw sockets.
Windows doesn't let you do this with their API, but somehow winPcap gets around this.
So your question could be "how can winPcap use raw sockets through my particular combination of host OS / hypervisor / guest OS"
maybe a more broad question that will also solve your problem is "winPcap in virtual machine"
Zitat:
Alternatively, you could setup a different VM environment using
Oracle VirtualBox. Install an XP environment on that VM and
configure the NIC (on the VirtualBox side). Set the NIC to Bridged
Adapter bridged with the appropriate LAN interface. Click on the
Advanced link in the settings tab and change the Promiscuous Mode
setting to "Allow All".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
WinPcap is installed on the system (as a matter of fact I just reinstalled to be sure). As it bothered me quite a bit, I've installed a Hyper-V Win 10 development environment with Codesys Control Win 64 Runtime and connected the IO directly in the ethernet port of my computer. This works fine & fast! The modules get an address assigned and I'm able to read the IO.
So I am pretty sure it is some (bad/weird) configuration of the server which holds all the VM's of the company. Since this is not a Codesys error, as it works on my PC, I'll go and figure things out with the IT-department.
If this error appears again I'll make to sure to attach a PLC log for future reference. If a solution is found, I'll update you as well.
Keep you informed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm testing Codesys Control Win (64-bit), latest available version, on a Hyper-V virtual machine. The installation of the runtime went smooth, as went the download of the application to the device.
But when scanning for the modules, the following error occurred:
What could be the cause of this. Could this be a network configuration issue?
Reno
Hi Reno,
Slave problem?
Reduce slaves, sounds for me like one is connected which has a problem.
So I would start with less and add one by one...till you have the one.
BR
Edwin
Hi Edwin,
Thanks for your reply. I would assume there is a corrupt module as well, if they wouldn't work on a physical server either. But they are all operational without packet loss on a physical server.
So it appears to be something with the virtual server. I have too little experience with how eeprom works and what could be blocking/preventing access to the slaves.
The weird thing is, the scan is able to detect the slaves. But unable to assign addresses.
Have you got any idea what could be causing this, given the situation determined above?
Reno
Hi,
please check in online mode the status Page of the EthercatMaster.
Do you see lost frames there?
BR
Edwin
Hi Edwin,
When I login to the Codesys runtime on the Hyper-V virtual server (without any slaves connected), the following statistics are returned:
It remains on 14 send frames.
Kind regards,
Reno
Hi,
one remark,
is really WinPcap installed on this system?
Nmap does not work. ( Will be fixed, but do not know when)
So please check if WinPCap is installléd on this system.
Could you add the plc log?
BR
Edwin
Profinet driver needs to send and receive raw sockets.
Windows doesn't let you do this with their API, but somehow winPcap gets around this.
So your question could be "how can winPcap use raw sockets through my particular combination of host OS / hypervisor / guest OS"
maybe a more broad question that will also solve your problem is "winPcap in virtual machine"
winpcap :
Hi Edwin, Campbell,
Thanks for both your replies.
WinPcap is installed on the system (as a matter of fact I just reinstalled to be sure). As it bothered me quite a bit, I've installed a Hyper-V Win 10 development environment with Codesys Control Win 64 Runtime and connected the IO directly in the ethernet port of my computer. This works fine & fast! The modules get an address assigned and I'm able to read the IO.
So I am pretty sure it is some (bad/weird) configuration of the server which holds all the VM's of the company. Since this is not a Codesys error, as it works on my PC, I'll go and figure things out with the IT-department.
If this error appears again I'll make to sure to attach a PLC log for future reference. If a solution is found, I'll update you as well.
Keep you informed.