kmonroe023

I figured it was something like that. I'll email support. Thanks, kmonroe

Hello, I recently attempted to upgrade the FW on a 465 PMAC processor and discovered that the ethernet ports will no longer start at boot after the update. I can connect via the serial port and start the ethernet ports using ifup, so I think the network config in interfaces is ok. Once I start the eth ports I can connect using the IDE. Once connected, the FW update appeared successful and I was able to download and run my project. If I reboot or power down the processor, I have to connect serially to get the eth port running again. Running IDE V 4.5.2.9 Interfaces file attached. I've tried to flash it back to 2.5.0.4 and 2.4.0.180 to see if the network issue would fix itself; it didn't. Eth ports started at boot with both versions of FW before the 2.5.20 update. Any idea how to fix this? I assume some startup script isn't working correctly, but I'm not familiar with Linux so I don't know how to proceed. Thanks, kmonroe interfaces

We typically use the system setup utility within the IDE to initially setup motor data structure elements. We use 320VDC servo motors and 230VAC Geo Direct PWM amplifiers, with Gate3 UMAC axis cards. We recently noticed a discrepancy between the value calculated by the setup utility verses the formula listed in the documentation for the PWM Geo drives. We use dual-axis GPL102 drives at 230VAC power input, which according to the drive documents yields a nominal DC bus of 325V. Our motor specs list a rated motor voltage of 320VDC. When we use that data per the equations listed in the Geo Drive PWM manual, we get motor.PwmSf = 14518. However, the setup utility is setting PwmSf to 18611 given the same data. Why the difference? Is there a risk of motor or amplifier damage if PwmSf is set higher than recommended by the drive docs? We use the amplifier db that comes with the IDE for setup. We've also verified that the motor voltage is 320VDC in the motor db's we've created for the setup utility. Thanks, kmonroe

We have some established programs running background C-PLCs that reference global P variables in the C code. We reference them using the notation "pshm->P[2]". These C-plc's have been running fine on other Power Pmacs for a couple of years. We recently upgraded to FW 2.4.0.180 on one of our 465 UMAC processors. The C code appears to build and download, but none of the expressions that contain global P variables seem to evaluate. No code changes in the project, the only change is new FW in the PMAC. We've verified that the PLCs are running by adding debug code that modifies a few variables in user shared memory, we then use the watch window and make sure the user shared memory locations update as expected when the C-plcs are running. Any ideas as to why just the global P-variable expressions will not evaluate? We've tried cleaning the project before build and download, reboot then build, etc. We're using IDE 3.1.2.2. Thanks, kmonroe

I agree a better method of managing IDE and FW versions is needed. We have 30 to 40 PMAC systems in our production facilities right now, all running various versions of FW and IDE. While upgrading FW on some of our production equipment we've broken projects than ran fine for months or years on older FW, so our support folks are hesitant to upgrade FW on PMACs that are running fine. On the other hand, trying to support all those different FW versions can be a major pain.

Hi Brad, I'm Jhendges co-worker. I've been using the "Run As Administrator" option when I run the setup program and I had the same problems with the setup program failing to start. While trying to install the IDE I noticed that there were multiple instances of "msiexec.exe" running in Task Manager. Every time I'd try to run the IDE setup, another instance of msiexec.exe would appear and sit at 0% CPU. Eventually, I started killing instances of msiexec.exe and the IDE install suddenly started again. It took a couple of tries but killing the MS install processes this way finally resulted in a good install. The IDE is now up and running fine. It just seems to me that the uninstall process for the V3 IDE (3.0.1.0 specifically) left some stuff on my system that caused grief for subsequent IDE setup programs. I just got lucky in that killing stuff in Task Manager got the install running again. I'm running Win7 64-bit Professional.

The release notes for the latest version of FW (2.3.1.0) indicate that an Ethernet/IP stack was added. Any documentation on how to use it? Thanks, kmonroe

I was able to re-create this problem; seems to be related to the firmware update process. After updating firmware to V2.xxx, background C plc's did not seem capable of reading or writing global P variables. Even after resetting ($$$) the motion system. It was not until I rebooted the Linux OS, followed by a build and download, that I was able to get the C plcs working properly. I had this problem while upgrading to V2.1.1.3, and to 2.3.1.0. PMAC's in question were dual core (465) UMAC processors. Have not tried this with a single core processor.

I recently tried to update a Power PMAC 465 UMAC processor from FW 2.1.1.3 to the latest FW version 2.3.1.0. I used IDE V3.0.1.0 for the firmware upgrade and subsequent project download. I found that background C plcs that ran fine in 2.1.1.3 no longer appear to be running after upgrading the FW. I can start and stop the PLC's from the task manager and/or using the UserAlgo terminal command. Even though the task manager shows they are running there is no indication that they are actually doing anything. For example, one C plc (see code below) does nothing more than invoke the fsave() command when a global variable is set, then reset the global, I also had it increment a p-variable just so I could monitor whether it was running or not. The other two bgcplc's that do more complicated stuff also don't appear to be running, even though task manager insists they are. All this worked fine prior to the FW upgrade. Any idea what could've gotten broken??? No code changes, just build and download after the firmware update. **** update **** I just noticed that pp_proj.h is now completely empty!!! Normally it defines global variables and pointers pp_proj.h gets built when selecting "map PMAC variables" but gets cleared after the project download The bg plc's can't read/write P variables, but any expressions using pointers to share user mem work fine. For example: pshm->P[x]=pshm->P[x]+1; does not work *pntrShm = *pntrShm + 1; works as expected. *************** Code for test bgcplc #include #include #include #include "../../Include/pp_proj.h" #define _PPScriptMode_ // uncomment for Pmac Script type access //#define _EnumMode_ // uncomment for Pmac enum data type checking on Set & Get global functions /* fast save function * set bDoFastSave from script environment, cPlc runs Fastsave function * set variables to be saved in "pp_custom_save.tpl" * FastSave will save any parameters listed in the pp_custom_save to non-volatile memory */ #define P7 pshm->P[7] void user_plcc() { if(pshm->P[bDoFastSave] == 1){ FastSave(); pshm->P[bDoFastSave] = 0; } if (P7 > 100000){ P7 = 0; } P7 = P7+1; }

Perfect...thanks for the update.

Was there any resolution to this? I am having the same problem with a new V3 install. I did contact technical support on Friday, but I have not heard back from them yet. Hoping that pinging the problem here will help. For what it is worth, I was running V2 IDE with no issues. When I installed V3 I was not able compile c-code for the 465 processor. Other than the problems with not being able to compile, I liked the new shell. Overall it seemed snappier and and I really like that intellisense works offline now! I have a laptop running Win7 Enterprise 64bit, with 16G ram. Regards, kmonroe

I wonder if Amar is trying to connect to the ETH0 port using a network adapter that is configured for 100Mb/sec. The ETH0 port on the 465 PMAC is Gigabit only. It will not auto-negotiate down to 100M. He'll either need to setup ETH1 using the Usb stick method, or connect to ETH0 using a NIC card with Gigabit capability. See this thread: http://forums.deltatau.com/showthread.php?tid=2093

Thanks for the suggestion, I will trying lengthening the timeout. The project isn't large, but I do have a couple of background C plcs and a rather large realtime C usrcode routine. All of that can take up to 20-30 seconds to compile. I wonder if that is causing the timeout?? I am using a UMAC Power PMAC, with the dual core (465) processor.

Occasionally config file creation will fail when trying to generate a configuration file in the the solution explorer. The text in the output window is: Could not generate the project configuration file. Generation of pp_diff.cfg failed: Error in section [bUFIO] I've tried fixing this by re-compiling and downloading the project, then saving. Sometimes this will allow config file generation, sometimes not. What causes this error? IDE Ver 2.2.0.39 Firmware is latest, 2.1.1.3 I believe. Thanks, kmonroe

I have a question regarding how to update/change motor servo gains if the feedback device is changed. The application is a rotary servo motor driving a vertical slide via a ball-screw. There are two encoders in the system, a quadrature encoder that is built into the motor, and a BissC absolute encoder that is connected directly to the slide. The initial motor setup and tuning was performed using the quadrature encoder. The existing gains work well with the slide & load attached and the quadrature encoder closing the position and velocity loops. I'd like to use the existing servo gains, but close the position loop using the absolute encoder; it's connected directly to the slide and has a much higher resolution than the quadrature encoder. If I update pEnc and PosSf to use the absolute encoder, do I need to update the servo position gains to maintain the same bandwidth and performance I have with the quadrature encoder (See below for Motor.PosSf info)? If I do need to update the position gains to use the absolute encoder, is there an easy way to scale the existing gains if I know the difference in resolution of the encoders? // both encoder scaling factors setup to output millimeters // absolute encoder, 1 nano-meter resolution (1 million counts per mm) Motor[5].pEnc=EncTable[10].a Motor[5].PosSf=1/1000000 // incremental encoder on ballscrew w/ 2mm pitch, 8192 counts per rev Motor[5].pEnc=EncTable[5].a Motor[5].PosSf=2/8192