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.

I did do a $$$*** SAVE $$$ command sequence when I installed the board. I does appear to have some issue with the ACC-5E clock. What can cause the clock not to function? What is the issues that may arise if I use the clock on one of the ACC-24E3s that we have in our system? Will all MACRO functionality still work?

Unfortunately, I just checked. All of the Gate3 cards (ACC24E3 and ACC59E3) have Gate3.PhaseServoDir=3 already and it doesn't seem to work. The cage has a Power PMAC, an ACC59E3 (Gate3[0]), an ACC24E3 (Gate3[8]), and an ACC65E (GateIo[9]) along with the ACC5E (Gate2[0] and Gate2[1]) being look at. It should be noted that PhaseServoDir for Gate2[0] is 0 and for Gate2[1] is 1 (which I suspect is correct). As a quick check, I changed the Gate2 PhaseServoDir (s) to 3 and set it to 0 for the ACC24E3. The NoClocks flag clears. Is it possible that the ACC5E is not producing a Clock signal or is there some way to disable the ACC5E clock and it needs to be re-enabled. It's a brand new ACC-5E that we just received.

I've done it that way (using something like... struct timespec startTime, now; clock_gettime(CLOCK_REALTIME, &startTime); // do stuff clock_gettime(CLOCK_REALTIME,&now); ) but I think you could also use changes Sys.PhaseCount changes or Sys.PhaseDeltaTime and multiply it by Sys.ClockSf -- I tried it but got close enough to the same results for my tests that it didn't matter and returned to the timespec method.

Are this cards compatible? We have a Power PMAC mastering the card cage and, without the ACC-5E in the card cage, it utilized the ACC-24E3 clock for the Phase/Servo clock and everything runs. When we put our newly received ACC-5E into the system, the phase and servo clocks point to the ACC-5E but the phase and servo clocks stop running (the NoClocks flag becomes true as well). We can run MacroControllerInit and the terminal returns: Ring 0:Includes the following Accessories ACC5E[0].RingMasterNum = 0 ACC5E[1].MasterNum = 1 but, the clocks are no longer running. Is there some test to run to ensure that the ACC-5E clock is functional or is this a compatibility problem.

We are really struggling trying to utilize cards from the Power PMAC in a second card cage via a ACC-5E and 16-axis MACRO CPU card. We have multiple (4) ACC-24E2A's and an ACC-36E in the second cage and are trying to utilize all the axis (actually only 14) as well as read analog inputs off of the ACC-36E. The instructions for accessing MACRO bus I/O and servo nodes seems extremely confusing. When we run (the undocumented) command MacroControllerInit, the terminal returns Ring 0:Includes the following Accessories ACC5E[0].RingMasterNum = 0 ACC5E[1].MasterNum = 1 From here, I need to know how to initialize the MACRO CPU to read the ACC-36E (and if possible read it through the ADCDemux calls or block memory copies) as well as read the encoders off the ACC24E2As. Is there a quick tutorial that shows this to make our lives easier. A lot of the settings (like Macro.Enable) seem to have hidden flags that are not detailed in the software reference manual. For example, the Node bits are 0-15 but nothing notes that 2,3,6,7,10,11 are I/O while 0,1,4,5,8,9,12,13 are axis nodes as shown in the MACRO Training Seminar slides (slide 38) not to mention the requirements for bits 14 (I/O vs Master) and 15 (Protocol--don't know what type 1 protocol means). Can any of these commands be made in the terminal window? When we try to run any of the MacroSlave or MacroMaster commands, the terminal hangs and we have to 'Ctrl-C' to disconnect/connect the terminal window. In the MACRO Status window, we seem to only be able to get the SynchMaster flag to change to true (MacroControllerInit). We cannot seem to change any of the other flags. We urgently need to get this working. [quote='bradp' pid='618' dateline='1281640063'] Macro on PPmac is essentially the same as Turbo PMAC except that setup is done via structures and not addresses. I have no quick start guide, just the data in the saved data structures manual and this project from a real application. It was for Etel drives so drive specific data will need to change but it will give you a good list of structures to verify the setup. // Gate2[i]. MACRO Ring Setup Elements 55 Gate2[0].MacroEnable = $0fC133 // master 0 and 5 servo nodes Gate2[0].MacroMode = $4070 // make synch master Macro.TestPeriod = 50 // macro ring cycles in test period (i80) Macro.TestMaxErrors = 2 // max macro errors allowed in test period (i81) Macro.TestReqdSynchs = 2 // min synch packets needed in test period (i82) [/quote]

Thanks, I did get the code from that but had a mistake when I implemented it. I accidentally shifted everything by one location because I was using indices 0-15 instead of 1-16. I modified the code to correct and it appears to be working correctly.

Thanks, that is a great help. I'm still having a lot of difficulties trying to read analog inputs (just voltages) with the Power PMAC and the ACC-59E3. I noticed that you created a thread on "ACC59E and Power PMAC". Does anyone have a similar thread for the ACC59E3? The instructions for the ACC59E (GateIO) don't seem to apply for the ACC59E3 (Gate3). I used the code suggested in the ACC59E3 User Manual (Appendix E) but the values returned seem to cycle inconsistently. I suspect that some of the Gate3 flags are not set properly. All I want to do is ready differential voltages on all of the channels.

Does anyone have information about the polarity of the jumpers on the ACC-59E3? The manual says to set the jumpers to 2-3 for voltage sensing and voltage output but does not specify which of the 3 pins is 1. If you go by PCB layout convention, the square pin would be pin 1 and is the pin farthest from the front plate but, if you look at the way the pins are shown in the manual (assuming the top of the board is up), then pin 1 would be the pin closest to the front plate. The picture or the board in the manual does not show in which order the pins are either. I just want to make sure that it is setup for voltage mode before starting.

Having problems with the Real-Time Workshop coder for Matlab R2010b. The ertlib.tlc is trying to include file PPMAC_param_update.txt and the PPMAC_file_process.tlc file is trying to include PPMAC_param_mapping.txt but I have no idea where to get these files or, if I am to create them, what the format of these files is.

Once I get the board back, how do I know that the ECO was implemented. The returned board (same serial number {C000097DA}) does the exact same thing as it did before I sent it away for the ECO implementation. The lower channels (0-7) work but the higher channels (8-13) do not--all AdcDemux.ResultHigh read 0. Even the ADCuHigh never changes (the ADCuLow does cycle through correctly). We appear to have found the problem. We are using the +12V/AGND to power a thermistor circuit and the +12V pins (#7) read correctly on the lower channels (actually read 15V) but are floating on the upper channels. The manual shows that the connectors are the same but they do not appear to be. Is this a known issue?