windell747

Its possible that you're PID tuning might be causing the motor to just when it is being enabled. You can verify this using the scope feature of the IDE and look at the following error for motor 1 when you enable it. If you want to just get things going and do the tuning later, make sure your setup in in a SAFE STATE for the motor to run away. I'd say just have the motor sitting on its own then set the following error to inf corresponding to there is not following error limit at all. Then try to enable your motor to see if it still trips. Another thing, make sure that your encoder direction sense is correct. If it isn't then this will definitely cause a run away. You can fix this in software by setting the scale factor to a negative or positive number depending what it is now. AGAIN MAKE SURE YOUR MOTOR IS IN A SAFE STATE TO POSSIBLY RUN AWAY UPON ENABLING IT.

The main reason for the 460EX is that all of my development has been using the 460EX and my configuration file is for that CPU and firmware. I also remember that the way my code is written there might be a possibility that I would need to rewrite some of my code to use newer firmware versions. All of this still needs to be confirmed, but right now even the 465EX isn't "drop in compatible" because I don't know if my current configration is useable without modification. Pretty much Im looking for a spare for the 460EX so if in an emergency if the CPU fails that I would swap it out with another 460EX. I'll soon be putting in the time to go through with upgrading to our 465EXs and see if the project still works, but haven't found the time to do it yet.

Fixed this. I did a save with no project loaded and did a processor ($$$) reset and it came up fine the next time.

Fix described here: http://forums.deltatau.com/showthread.php?tid=2988

Just fixed. I opened the file in the directory that the message instructs: /cygdrive/c/Users/Windell/.ssh/known_hosts and deleted the entry for the IP address that has the conflict. After that the compile and download completed successfully.

Hello, I'm upgrading to the EX465 CPU from the EX460 and I'm getting the following error: I understand that this is because I'm taking a previously loaded project that was on my EX460 and I'm trying to compile on a EX465 using the same IP address. I could change my IP address, but I really need it to stay what it always has been. The IDE says that I can just build and redownload the project, but I get the error again on the second time. Im sure someone else has solved this? Mahalo in advance! windell

I'm having the same problem too. Could you please share how you fixed this?

I tried notch filters and they worked very well, the problem is that I lost my positioning accuracy and I need to hold position as close as possible. Everything adds up and the velocity and acceleration following error ripples are what's hurting the most at the moment Try to increase your Ki gain and decrease your Kd gain a little. Your Ki should decrease your steady state error. Dont add too much Ki or your system will go unstable. Also relatively, whatever change you make to Kd as a rule of thumb make a fraction of that as the change for Ki. To be safe just change one at a time starting with changing Ki a little bit and see how it does. If its not your steady state position accuracy that you need to improve, but your tracking position accuracy, then increase your Kp.

Hi, I just installed a new 465EX CPU in my UMAC and I'm getting a HWChangeErr & PwrOnFault at the same time. I'm attempting to upgrade from the 460EX. The IDE im using is 2.0. Per the 465EX manual, I checked that the jumpers are correct and they are what they should be. I understand what is causing the HWChangeErr, that I changed the hardware since the last save was performed, but I don't know about the PwrOnFault. When fully booted, the RDY LED on the from faceplate is illuminated. I could just so a save and reboot and see if it goes away. Has anyone experience this when doing an upgrade?

Hi I'm wondering if there is a way to transfer a 460EX configuration file to the 465EX? All my development has been on the 460 and Im attempting to make the upgrade for the 465EX and I would like to not need to manually go in and redo everything manually. I have the pp_save.cfg as well as the .ppm file and the incremental configuration generated by the "Generate Config File" option. thanks, windell

Hi, Im in need of a replacement 460EX CPU, does anyone have one available for me to purchase? thanks, windell

Aloha Inert, Have you verified that there isn't any noise getting into your feedback? I would use the scope feature of the IDE with your motors absolutely still, clamped or something to make sure that your feedback sources aren't noisy. I would prefilter as a last resort since that is really to take out resonances and might masked a larger issue. I would start by removing power from your motor and see if the noise goes away, the closest high current device to the encoder or feedback may be the culprit. If your feedback is clean, I would lower your Kp a little bit or increase your Kd. It could be possible that your Ki is too high. You can zero out your Ki and just working with Kp and Kd for now to see if the ripple goes away.

Thanks Steve for talking on the phone today. I sent an email back to delatau support, but I'm going to continue to post here so that others may benefit as well. Here is what I’ve done per Steve Millici’s instructions: -Done a factory reset of CPU using $$$*** -Did a “Clean” of the project -Went into the project file structure and deleted the files in /bin of the project -Unloaded the project via the IDE -Reloaded the project -Downloaded the config file using the IDE -Did a save and reboot of the PMAC -Verified that the configuration is sticking by looking at entries in the Delta Tau->Setup Variables Still no luck. I've also reloaded the firmware of the PMAC using the IDE. I've confirmed that the kernel is also identical. Additionally, I've written my own little cplc for cplc3 and tried to run it and it also doesn't run: #include #include #include #include "../../Include/pp_proj.h" void user_plcc(){ pshm->P[99]++; } The only difference that I see is that one PMAC had a 460EX processor and the other one that doesn't work is a 460EXRev.B

Aloha Jeff, A few years back I was attempting a similar thing to what you're doing now. I contacted delta tau and they also told me that those functions are for internal use only and referred me to their IDE. What I did is I used the sinesweep function in the tune directory to excite my system through a range of frequencies. If I remember right I pretty much had to reverse engineer it myself since I have additional hardware connected to my pmac that wouldn't allow me to use the tuning aspect of their IDE. So instead what I did was just typed the command "sinesweep" and a list of arguments was explained to me: sinesweep The number of arguments specified is incorrect. You need 7 Arguments for this function Motor Number Excitation Amplitude Starting Frequency of sinesweep Ending Frequency of sinesweep Sine sweep time Sine sweep Method (0 or 1) Kill flag (0 or 1) Please try again. I got the unit/descriptions from looking at their tuning part of the IDE and taking the arguments above and relating them to what I saw in the IDE. From what I remember, other than the frequency units, the units were from your scaling factors in your configuration. Mine were just in encoder units. Sweeptime was in seconds and the Sinw sweep method corresponded to a linear chirp or a log chirp. I made sure that I put the system in a safe state before trying my first time. And even then for my first time I tried something insanely small for amplitude to see what it did. Even then I had my hand on the kill switch to cut the power if things ran away. Hope this helps! thanks, windell

Hi, I have two identical PMACs running identical code sets. However, one of them isn't allowing any of my bgcplcs to run. I start the cplc is started by running the following command via my C code: snprintf(commandString,256,(char*)"UserAlgo.BgCplc[%d]",value); reply = SetPmacVar(commandString,1); // Enable BGCPLC0 thread I have 3 bgcplcs that run so in the above code, "value" would assume 0, 1, or 2. I print out the reply and it reads 0. I also type UserAlgo.BgCplc[0]=1 for example in the terminal and then query UserAlgo.BgCplc[0] and it returns 0. Im a bit confused since both of my setups have the same hardware and are running the same code, yet I can't get any of the cplcs in the second PMAC to stay running. Oh and the config file for them is also the same. I've attached a copy of one of the cplcs code for reference thanks, windell bgcplc.c

Thanks Steve. Sys.CardIOAutoDetect = $2 is the result, but I don't know exactly what that means in terms of if the PMAC is detecting the Acc14E card. Is there a place I can look to to find examples for how to use the command line to inquiry the bits? In my CPLC code, I use pGateIO = GetGateIOMemPtr(1) pGateIO->DataReg[2] = CPLD_DATE_ADDR; nanosleep(&delay, &remaining); CPLD_DATE_REG = (pGateIO->DataReg[1] & 0x0000FF00) | ((pGateIO->DataReg[0] >> 8) & 0x000000FF); However, I'm not sure how the "1"in the first line is arrived at. Also I'm not sure where the "2" is arrived at in the second line. Then I'm not sure where the "1" is arrived at in the fourth line. I've looked through the software manual and users manual and I'm having trouble putting the pieces together. Would someone be so kind to explain? I'm trying to figure out where the "knobs" are.

I have two Power PMACs. Both have Acc14E cards reading a bunch of bits. Both were working fine, but one just started experience ethernet port issues. So I swapped out the CPU board with a replacement. The ethernet port now comes up fine. I put the same firmware as the old CPU, 1.5.8.0 and I loaded the same configuration. However, how my background process (same exact one as before) reads the bits from the Acc14E, they're all zero. I'll not that I didn't change anything with the Acc14E and that I only swapped the CPU board. The firmware, configuration and background programs should all be the same. I've added my cplc that reads the Acc14E pins for reference. This file remained untouched. Does anyone have any insight what my issue might be? bgcplc.c

Hi KEJR, I was just wondering if you have experienced any issues with "ntpdate" taking up to many resources or messing anything up on the PMAC side. I understand that installing and running ntpdate is a standard linux thing to do, but I just wanted to check since the PMAC is using a real time operating system. Right now I'm writing over our network to a time synced logserver, but considering that I'm sometimes writing strings are 1 kHz rates, I think it would be better to do so locally, so now the timestamps matter. thanks, windell I just looked at my notes and I had to install the "ntpdate" debian package. Its been a while since I did this, but I seem to recall it being a very simple install and it just worked. Keep in mind that with any debian package install you need to deal with the read only filesystem as described in many other posts on this forum. Its probably been over a year since I've installed any deb packages, I hope that debian is still maintaining this version on their servers. For me, I have made all the changes and imaged the flash on the PPMAC so I haven't had to go through this process recently, I just keep restoring the image on new PPMACs that we get. Let me know if you need any more help. KEJR

Hi, I've been attempting to perform open loop step and sine tests, however my IDE crashes on me. So as a secondary route I found the tuning functions in /opt/ppmac/tune. I have also written my own C program that does the data gather manually so that I can do without the IDE at the moment. When I run the functions without arguments I get an explanation of what the arguments are. However, there aren't units on some of the argument explanation. For example when I run openloopsine, I get the following response root@128.171.80.202:/opt/ppmac/tune# openloopsine The number of arguments specified is incorrect. You need 5 Arguments for this function Motor Number Excitation Amplitude Frequency of the sinusoidal Repetition number Kill flag (0 or 1) Please try again. Question: What are the units of excitation amplitude? I'm guessing DAC counts. Frequency of the sinusoid? I'm guessing is in Hz. Also what does setting the Kill flag to 1 do? Is there any documentation somewhere on the use of these functions? thanks, windell

I've attempted to start the tuning process with the old IDE (1.6.9) and I'm getting the same behavior that the IDE crashes when I try to do a step. I'm in the process of upgrading my firmware, but there are some unexpected hurdles that I need to leap over before that happens flawlessly. Any suggestions I should try? I've tried tuning using the newest IDE and 1.6.9 and both do the same thing.

Hi Steve, I'm not sure why we have Sys.CPUTimerIntr = 1 in that config file. I was taking a look at the software manual and I don't think we need it to be a value other than 1. I'm guessing that for firmware 1.5.8 the default isn't Sys.CPUTimerIntr = 1 and so is why when I generate a config file that it lists this setting as a change from the default? Should I just delete that listing from the config file and attempt to download to the PMAC that is running the newer firmware?

For some reason the forum isn't allowing me to attach these files. So I'll just email to you. thanks, windell

Hi, I'm in the process of upgrading from firmware version 1.5.8 to the most current version and I am running into an issue. It has to so with the attached CPLC. Background: Near the bottom of the file a set of IO pins on the attached ACC14E card are read and stored in P-variable P[399]. The CPLD_DATE_REG is a macro for P[399]. CPLD_DATE_REG is binary word which is read by a background C program and based on the value of this word, the C program behavior changes. Problem: When I run my code in firmware 1.5.8, the word reads a 48875, however, when I upgrade my firmware to the newest version and run my project again, the value reads 0. When I switch back to firmware version 1.5.8, I get the correct value of 48875 again. Question: Would someone be able to take a look at my CPLC program and tell me if I am doing something wrong in terms of the newest firmware? I honestly don't see what would have changed in the new firmware to break the operation of my code. thanks, windell bgcplc.c

Thanks Steve!

This configuration that I'm trying to load was saved from a working system that was running 1.5.8.0 prior to upgrading the firmware to the newest version. So it has been used before but only on the 1.5.8 firmware. The hardware that is being used is Power PC 460 EX ACC-24E3 x2 ACC-59E3 x1 ACC-14E x1