pennells

That does seem to work for the SEL lines (upper 8 bits) but the DAT lines seem to still only work as outputs. I set Gate2[0].PartData[0] to 8 and the DAT lines seem to work as outputs. Is this what I was supposed to and/or allow to do?

This seems pretty straight forward as described in the software user manual. It seems that, if I want to use DAT0-DAT7 and SEL0-SEL7 as outputs, all I have to do is: Gate2[0].MuxMode = $FFFF; Gate2[0].MuxDir = $FFFF; Gate2[0].MuxPol = 0; //don't really care about polarity at this point Then, toggling Gate2[0].MuxData bits to toggle the output but the output seems to be set high regardless and the read-back value only changes if I change the MuxPol. We did similar functions on LowIo and everything worked as expected but it doesn't appear to work for the JTHW lines. Is there something missing in what we are doing? Do I have to use MuxIo? (Right now, MuxIo.Enable = 0 so I figured that it shouldn't interfere.)

Is there a way that, while using the IDE, you can change the gcc compiler options for the generation of usralgo.ko? It appears that the -O2 option is being added to the Makefile and can result in incorrect compilations of for loops assigning values from arrays of double in structures. Manually unraveling the loop into statements works correctly but the assignment in the for loop does not. This seems to be a reported bug to gcc (as late as version 4.5.2) when using the -O2 option but we can't seem to not use the option.

Finally, got this specialized encoder and your solution worked perfectly, thanks.

According to the training slides (Power PMAC Computer 2011-04), the libppmac.ko (or rptmac.ko) has useful math libraries for the kernel object. Is it possible for a usralgo to use these math functions and, if so, how does one configure the IDE so that it finds and links to them? I may be forced to do some of the function in a rticplc if there is no way to use these math functions. I just wanted to know if that is what I have to do. This seems to be more inconsistent than I originally thought. Sometimes the math library functions (pow, sqrt, fabs, sin, exp) work and can be included in the usrAlgo and others times they do not. It seems like the only way to determine if one will or will not work is to download the assigned servo algorithm and see if that motor correctly assigns the algorithm (ie. Motor[x].Ctrl = UserAlgo.ServoCtrlAddress[x]). If the function does not work, no errors are reported but the Motor[x].Ctrl points back to the Sys.ServoCtrl. How can I determine when or why the function doesn't work. As an example, in my motor0_servo function, I added the following line (where value was declared as float): value = exp(2.33L); -> this one works value = exp(2.0L); -> this one does not work I can switch back and forth and the first one always works and the second one always fails. I can't for the life of me figure out how this is even remotely logical. I tried again with value declared as a double and both seem to work. It would appear that there is some sort of casting issue or the header has the float library but the linked library only uses double. I'm getting very frustrated trying to add some algorithms and then spending a lot of time trying to determine what in the algorithm make the userAlgo address fail. There has to be some explanation to what will and what won't work so I know what capabilities I can put into my servo algorithms.

We have a rather specialized type of SSI encoder which have an extra most-significant bit that specifies the health of the encoder information (IE 18-bit encoder that sends 19 bits of data with the MSB as a health signal). Is there a way to use the encoder information directly in the encoder table while masking off the extra MSB so that the information is correct. I figure that I can read that bit directly from the ACC24E3 data structure but I figure that the extra bit will mess the EncTable reading up when it wraps around. I tried sett the type to 1 and using index2 (right-shift) {13} and index1 (left-shift) {14} to get rid of the MSB but that doesn't appear to work--if the MSB gets set, the position data goes to some small negative value regardless of the other bits. Any ideas of a possible solution?

I'm having a similar problem. I create a user servo algorithm. I assign it to a motor. It compiles correctly, creates a usralgo.ko file and the file downloads (doing build and download all) but the UserAlso.ServoCtrlAddr[0] and UserAlso.ServoCtrlAddr[1] always equal 0 and the motor servo always uses the default PID. Since the address are 0, I obviously cannot assign them. Is there something it the project that may be missing. I've done this repetitively manually deleting the ko file and doing a clean to ensure nothing is left behind but end up with the same results. So, in the end, it was because fmin and fmax are not in this version of math.h. The real problem is that the IDE and all error logs did not report the error. They downloaded and just did not successfully run. It is very difficult to find errors in userAlgo with this setup. We found it by creating a duplicate of it as a background c program.

Thanks, BradP. I was so close but missed the fact that it was Phase D (not Phase C) that output the PFM on the card so I had not set bit 3 of OutputMode (was 3 now set to $B). Setting that bit solved all my issues.

Is there an equivalent way to do the simulated motors using an ACC-24E3 board to take the simulated servo output and feed back the results since it does not have the TimeBetweenCts element. I can't seem to figure out how to do it without that variable and this is actually an important test for us as it simulated the backplane traffic before we get all of our motors. Is there somewhere else that I can point the pEnc1 so that the phantom joint actually moves?

In BradP's post, it suggests entering the following: Gate2[0].ServoClockDiv = 1 Gate2[0].PhaseClockDiv = 0 Gate2[0].PwmPeriod = 6527 But, setting the ServoClockDiv to 1, seems to mess up the reported servo freq and the time on any plots that are gathered. The IDE reports that the frequency is still 2.2589kHz but it should report twice that. The time calculated in the plotting app uses the 2.2kHz clock so that the reported time is twice as long as reality. I've switch the ServoClockDiv back to 3 since it creates an issue that took me a while to figure out. Is this a know issue. Should I put it into BugZilla?

It's really too bad that this isn't clearly pointed out. I was following the ideas from the "PPMAC support for Macro?" discussion and no one mentioned setting MI1996. The setting of MacroMode to $4070 was suggested by a Senior Member but when I went to implement it, I hadn't noticed that the 6th bit was a status bit that was being suggested to be set. Between the issue that I mentioned in the "PPMAC support for Macro?" discussion (our ACC-36E interfering with the MACRO16 CPU or the ACC-5E (when we tried the card in the primary cage)) and this issue, getting the MACRObus to function correctly for both servo and I/O was very difficult but I would have thought it would be easy. I think a document for use of MACRO16 CPUs through ACC-5E for remote functions is an important document to create since MACRObus functionality is important to a lot of people and not really discussed in a central location. Even the 16-Axis MACRO CPU SRM is a hard to follow in that, the introduction of MI Variable reference (pg 1) mentions that the node numbers are 0 to 15 but the idea of adding 1000 to the variable number for the upper 16 nodes isn't mentioned until the various summary sections (pg 5, 9, 13, 23) that are not highlighted or tied to the pg 1 introduction. I was lucky to have notice it because I tended to head directly to the MI variables that I was trying to use. It would have been better to mention it in the section that says the nodes can only be 0 to 15.

We were having problems using the upper 8 servo nodes on the 16-axis MACRO CPU card through our ACC-5E. We set the MacroEnable and MacroMode as follows: Gate2[0].MacroEnable = $0FFFFF //6 i/o nodes, 8 servo nodes Gate2[0].MacroMode = $4070 Gate2[1].MacroEnable = $1F3333 //8 servo nodes Gate2[1].MacroMode = $50 After a bit of trouble shooting, we discovered the following: MS,MI996 returned $F3FFF (as expected) but MS,MI1996 returned $1F0000. We manually set MS,MI1996 to $1F3333 and did a MSSAVE0, MS$$$0 and everything worked correctly. Is this an error? Was the MacroEnable supposed to set the value or are the I996 variables not related to the MacroEnable flags.

We seemed to have got this working--well at least with the ACC-36E. Apparently, because our ACC-36E was at $A00000 ($8800), it was interfering with the ACC-5E and MACRO CPU. Most of our difficulties went away when we moved it to $B00000 ($8840). The only other problem that we ended up having was accidently enabling both manual and auto transfers so the data was jumping around. We've corrected that. We'll look into the ACC-24E2As next but that does look easier and we have a bit more experience with the MACRObus interface to the PowerPMAC now.

Well, it no longer really matters. I've save the settings with cid[4].dir = 1 so it automatically gets set to that every time we do a $$$*** or reboot anyway but I did have to set it manually in the first place.

Thanks, "Cid[4].Dir = 1" is the answer to all the issues. The ACC-5E now appears to work correctly using it's clock. Figures that we didn't get the ACC-5E until after we had updated to the latest firmware so I thought that it must be a faulty card.