sbondhus

I've had the exact same problem with our 4-axis demo box. There hasn't been a pressing need to fix it, so I've left it alone, but I've definitely had issues mounting USB drives in addition to problems changing the IP address settings for Eth0 and Eth1. I've successfully mounted USB drives and changed network interfaces settings many times on many different machines using the same flash drive. I also tried updating the firmware to 1.6.0.30, but it didn't help. EDIT: here's the response I originally got from smilici: "Does your Power PMAC have the Video option? These will have a blank “media” folder"

Richard, I saw your post, but it looks like to follow that setup strategy we need to (1) use the latest firmware (not so much an option for our stage of development; we're likely going to stick with 1.5.8.0 for this release), (2) use a Turbo PMAC (not an option), or (3) use the separate compile/download strategy suggested by steve.milici (seems to be more complicated and "disjointed" as daves pointed out). So far I don't see the benefit in any of those options over writing our own pattern check algorithm.

daves and dzrong, We do not have a TURBO station on hand to facilitate downloading these files, and frankly I'm not excited about using buffered commands (slow, as daves pointed out), and I'm unenthused regarding the limited MACRO support for PowerPMAC. You might be interested to know what we're trying to get around this. We are using A/B Quadrature encoders with a PowerPMAC CPU Master station and a 16 Axis MACRO CPU with four Acc24E2A cards (sounds very similar to daves setup!). We've found that we can jumper the A+/- and B+/- signals to the T,U,V, and W user flag inputs on the 24E2A Encoder Input, which we can read in the Gate2.Macro[j][3] status word. The top four bits correspond to the TUVW flags, with which we can do our own AB-Quad pattern check at our servo update rate. I'm not sure if this is recommended practice, but so far it is working great.

It looks like there is no direct way to determine that an encoder has faulted -- is that correct? We tried reversing resistor pack RP22 (as described in the ACC24E2A manual), wiring the signals to the T,U,V,W input flags, and setting MI16 to 1 (all as described in the MI16 section of the MACRO CPU SRM). Though we saw encoder loss hardware status bit change in MI927, it doesn't appear to change any of the bits in the MACRO status flag register. Furthermore, the amps did not disable when the encoder loss should have been detected (as described in the note in that section). The MI16 section also indicates that "automatic encoder-loss shutdown function... can be enabled with MI7", but the MI7 section simply says "(Reserved for future use)". For now, it looks like we'll be able to detect encoder loss by writing our own AB Quad signal pattern check and re-wiring all of our cables to jumper the A+/- & B+/- signals to the T, U, V, and W input flags, respectively, which we can then read through the MACRO status flag register Gate2.Macro[j][3]. Is this correct? Is there a better way to retrieve encoder loss information (that doesn't involve re-wiring our encoders)?

I am looking for detailed information on the contents of the Macro Nodes. In our particular case, we're using an Acc5E to communicate to a Macro 16-Axis station which controls four Acc24E2A cards with servo motors and quadtrature encoders, and I'm trying to understand the "16 bits of channel status/flag information/commands", i.e. the input and output of Gate2.Macro[j][3]. I've found various bits of information in various manuals, but never a comprehensive table.

Many thanks for all of your responses. I think we have a few good options now, and we got it working.

I'm trying to read the DIP switches of the cards in a MACRO station (Acc5E to 16-AXIS MACRO CPU) without having to manually remove the cards and mezzanine boards (because this is such a hassle). Is there a way to read the dip switch settings remotely? This is for Acc24E2A cards and an Acc36E card.

I have a project that currently uses a user-written servo routine for all kinematics and controls for a variety of motors and returns the user-calculated commanded voltage output from the servo routine to drive the motor. Two other motors are also assigned to this servo routine, though the intent and implementation (before my time on the project) for these two motors was to use the built-in Delta Tau servo routine (something like "return pshm->ServoCtrl(Mptr);"). The original coders of these routines used Mptr->DesPos and ->DesVel to attempt to command the motor to the desired position. This is similar to the method described in this previous post. I have tried using our code as it stands, as well as writing my own simple project based on the post linked above, and neither of them worked as desired. When I tried the example project linked above, I was able to command motion, but the motion didn't seem to follow any of the desired constraints (e.g. .JogSpeed, .MaxSpeed, .MinPos, etc). My question is this: If we want to continue commanding positions for this motor with the same routines we already have defined, but control it using the Delta Tau built-in PID controller, what is the most appropriate way to do that? The position we want to command to these motors is returned from function call in a separate user-written servo routine and stored in shared memory. Pseudo-Code for what we want to do: user_written_servo_routine_1(struct MotorData *Mptr) { Read sensors from input controls store sensor values in shared memory } user_written_servo_routine_2(struct MotorData *Mptr) { Update motor with desired position based on sensor readings obtained during user_written_servo_routine_1 return pshm->ServoCtrl(Mptr); ? } or, instead of commanding via a returned value in a servo routine, could we... user_written_servo_routine_2(struct MotorData *Mptr) { Format string based on sensor readings obtained during user_written_servo_routine_1 use Command(string) to issue jog command to desired motor } or, instead of using a servo routine to issue the command, read the desired position from shared memory and use a Motion Program to command the motor (I'm currently a little hesitant of this approach since we have no other Motion Programs in our project and none of our motors are currently assigned to specific coordinate systems, but if this is the correct approach I'm open to using it.

I added the "&*%100" command to pp_startup.txt, and that fixed the issue. Thank you for the help!

We do scale position to mm instead of default motor encoder units. I've tried setting the scaling in the Motor vs Encoder setup tables with the same run results. For our original setup we had PosSf=1 (scaling done in the encoder table), but I also tried doing the scaling in the Motor setup. Both had the same problem. Just today I tried setting the clocks back to the default speeds. It appears that because our clock speeds were reduced (Phase, servo, RTI, and background), the maximum jog speed was also reduced (apparently to by the same ratio as our servo cycle). Is this a bug, or am I missing a setting somewhere? It seems silly to me that Motor[x].JogSpeed is relative to the clock speed, especially since it is defined in units of "Motor units / msec". Our clock setup is done in a .phm file in the Global Includes directory. The relevant lines are as follows: Gate2[0].PwmPeriod = 7371; //Max Freq = 8kHz (117964.8/(2*PwmPeriod + 3)) Gate2[0].PhaseClockDiv = 1; // 4kHz Gate2[0].PhaseServoDir = 0; Gate2[0].ServoClockDiv = 3; // 1kHz //Clock (from ACC5E) Cid[4].dir=1; Sys.BgSleepTime = 4000; // 250 Hz Sys.BgWDTReset = 0 ; Sys.CompEnable = 0 ; Sys.CompMotor = 0 ; Sys.FirstEnc = 0 ; Sys.MaxCoords = 16 ; Sys.MaxMotors = 32 ; Sys.MaxRtPlc = 0 ; Sys.PhaseCycleExt = 0 ; Sys.PreCalc = 1 ; Sys.RtIntPeriod = 3 ; // 250 Hz Sys.ServoPeriod = 1 ; //1ms (1 kHz)

I have a motor set up to use the following parameters, but it's not driving the way I'd expect: Motor[x].JogSpeed = 0.04; // mm/ms Motor[x].JogTa = 1; // temporarily reduced to eliminate Ta as cause of slow movement Motor[x].JogTs = 1; // same note as .JogTa When I issue a jog command to move 100 mm (i.e. Position window reads 120mm, I command "j=220") and I observe the velocity in the velocity window in the IDE, it shows that I'm only moving at 0.017 mm/ms (~42% of the desired 0.040). I am not hitting the specified MaxDac limit. Observing values for the inner- and outer-loop encoders shows that they're tracking as expected, scaled to mm. I've tried doing a full reset ($$$***) or power cycle to clear any remaining values from previous projects. What else could be limiting the velocity?

Yet another similar issue: sometimes if we leave a machine running over night, even with no software loaded, when we come in the next morning we can still communicate with the machine on any processes that were previously open, but we cannot open new processes (such as a new GPASCII thread). If we attempt to SSH in (telnet connection attempts are refused entirely) with the 'deltatau' or 'root' usernames, we get the following messages: login as: deltatau deltatau@xxx.xxx.xxx.xxx's password: Linux powerpmac 2.6.30.3 #24 Mon Sep 10 11:26:14 PDT 2012 ppc --------------------------------- -- PowerPMAC Motion Controller -- --------------------------------- Could not chdir to home directory /home/deltatau: Input/output error /bin/bash: Input/output error login as: root root@xxx.xxx.xxx.xxx's password: Linux powerpmac 2.6.30.3 #24 Mon Sep 10 11:26:14 PDT 2012 ppc --------------------------------- -- PowerPMAC Motion Controller -- --------------------------------- Last login: Wed Oct 31 23:56:54 2012 from 10.32.4.132 /bin/bash: Input/output error

We're still trying to figure out the hard watchdog issues, but now I have another issue. We are occasionally seeing something that appears to be similar to a watchdog but with different indications. Normally with a soft watchdog I'd expect to be able to still communicate with the system. With a hard watchdog I expect to lose communication and see the red "WD" led turn on. Occasionally we see a different issue: we lose communication, the WD led stays off, but ALL accessory cards in the rack lose power (PWR leds are off, any Enc lights are off, etc). The Ethernet ports are still lit up as if they're communicating. Any idea what this is?

I found it confusing as well. I think the value you're looking for is Motor[x].Pos - Motor[x].HomePos. This is stated in 2012 PMAC Software Reference Manual in the Motor[x].Pos section, on page 769: "To calculate the position relative to the motor zero position, subtract the value of Motor[x].HomePos."

We get watchdog faults fairly often on my R&D project (once every few days). I'm trying to understand why they're happening and how we can prevent them or, at the very least, understand the cause. Currently I'm struggling to understand whether we're having "soft" or "hard" watchdog faults. I believe they're hard watchdog faults. Setup: Power UMAC rack with PMAC CPU and a variety of other accessory cards (almost a full rack) connected via Acc5E/fiber to a MACRO16 station with several other cards. Using firmware 1.5.8.0 and IDE 1.5.0.21. Symptoms: (1) "PWR" LEDs turn red (on a system with 59E3s) or indicator LEDs turn off ("PWR" and "Enc" on a system with 24E2As) , (2) PMAC unresponsive (via ethernet connection through company network; we haven't tried via RS232 yet), (3) "WD" led shows red on PMAC CPU card. As far as what is happening when the watchdog is tripped, I'm not so sure. It definitely happens if we do a "Build and Download" without doing a "$$$***" first (we think this is related to the three different user-written servo algorithms we have running on motors 0-30). Sometimes it happens when we're not heavily taxing the processor but the project is running (servo tasks, rticplc tasks, and background tasks, including UDP communication with a PC over the company network). I'd like help understanding: Which watchdog tripped ("hard" or "soft"). For either type of fault, what is the best way to find the cause of the fault.