Bartat

Hello, With PeWin32 4.4 (we used 4.2.14 until now) the Ethernet-TCPIP communication of the Windows10-PC with the TurboPMac/PC104 is now stable. Also our HMI application which uses the PComm32.dll communicates now stable with the TurboPMac/PC104 . After upgrading the Windows10/2016 and new installation of the PComm32 libraries the problem has been obviousley solved. Best regards Markus

Hi, we have the same issue now: Ethernet connection between WinPE32 running at a Win10PC and TurboPMac doesn't work. Mostly the connection is lost after some seconds after establishing it. Connecting via USB instead is ok. Pinging the TurboPMac from a Win10 command shell works without showing errors. Because of changing our PC Operating system from Win7 to Win10 we need a solution. Is there meanwhile a solution available? Best regards Markus SatisLoh

20KHz Phase and 10 KHz Servo clock The problem occurs also, when no motion program or RTICPLC is running Yes, they are still running. I checked this with the Linux console "top" command. But the gppmac processes have been terminated. They are not listed anymore, when i type at the Linux console the "more stat" command at folder /proc/xenomai. Four month ago, i tested a firmware from DTCA with debug infos. The gppmac exits with an error message. The C-programs are doing some TCPIP socket communications with other controllers for reading/writing some IO data over ethernet. They are still communicating with the other controllers after the fault has occurred. And they still increment global P variables, which I can see at watch window of the PowerPMac IDE. One of the c-programs can definitely excluded, because I removed it from the project and the problem still occurs. Only the modbus tcp client must running. I attach the modbus source and a part of the background plc, which copies the data from and to the modbus buffers. modbus.zip

Hello, since about one year we have a strange issue with PowerPMac which occurs very very rarely. We are not able to find out what could cause this problem. It occurs in random intervals between 2 - 10 days and not in a special situation. We cannot intentionally reproduce it. In that situation our system stops running with a sys.WdtFault=1, a so-called software watchdog fault. But this is only the consequence of the fact that the gppmac application has been terminated or has been crashed, possibly caused by an internal fault. The gppmac application executes our background script plcs and (of course) if gppmac stops working the sys.wdtimer is countdown by RTI and the system stops with Sys.WdtFault=1. What we see in that situation is that all background script plcs has finished their execution regularly. We are using two extra C background applications, which are accessing the user shared memory of the PPMac. One is an own written Modbus client, which communicates with three modbus slaves over the second ethernet port (eth1). But these applications are still running without failures when gppmac stops working. So it is unlikely, that the problem is caused by these applications. It happens on differnet CPUs and with different firmware versions. We have tested several firmware versions from 1.6.1.1 up to 2.0.0.14. Maybe somebody else has some similar experiences? Any ideas?

Hi, Bradp wrotes: >>In newer IDE and firmware the Motor[].DesVelZero will be removed from the intellisense. I'm a little bit surprised. Today i test this bit and i see, that it works. Is this intended? We have firmware 1.5.3.169 Best regards Markus