[Turbo PMAC and Windows 8.1 and 10]

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

[Turbo PMAC and Windows 8.1 and 10]

I use this driver for win 10 connect with Ethernet

and after some time about 15 min I lost the connection

It happened many times

I try win 7 with the same connection it stay connected

 

Is there any new driver that will solve this problem?

 

thanks

 

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

[Software watchdog fault, gppmac stops execution]

What are your clock speeds?

20KHz Phase and 10 KHz Servo clock

 

Are you running any motion programs or foreground PLCs (e.g. RTICPLC or Script PLC within the range of Sys.MaxRtPlc)?

If you're running motion programs, do you have very closely-spaced programmed points that might be overloading the CPU?

The problem occurs also, when no motion program or RTICPLC is running

 

Are you sure your C programs are still running when you get WdtFault=1? How are you checking this?

Can you list your C code? Many WdtFault=1 conditions I have encountered were caused by C programs.

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

[Software watchdog fault, gppmac stops execution]

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?

[Des_Vel_Zero status bit not working/not accessible]

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