pennells

Where is "Sina's routine" to bit-bang the multiplexed thumbwheel port on the ACC-5E?

Thanks. That works great. I didn't question it because it was similar to the 24E2A.

I see to be missing something. I did all of the above and try to drive the virtual joint in open-loop or closed-loop and it doesn't move (like the brakes are on). The Dac shows it's being driven and, in closed-loop, the following error goes up but the actual position and velocity does not change. I figure it must be some simple setting somewhere that I missed but cannot figure it out.

Thanks, that is exactly what I needed. I had problems for a bit because my routine had a return (of zero) which trashed all the motor data but I've resolved that and this solution works just as desired.

Is there a way to keep the existing Power PMAC PID loop but substitute a user-defined specialized velocity feed forward function or do I have to replace the entire PID loop?

The only thing that looks close to a serial number is the number on a bar-coded sticker which reads C00097DA.

Is there any way to find out the address of the boards without taking them out. We have 1 Acc24E3 (reported as ACC24E3[0]) in slots 1 and 2, two Acc24E2As (reported as ACC24E2A[6] and ACC24E2A[7]) in slots 3-6, and the one ACC-36E (reported as ACC36E[1] which I do know is at $B00000) in slot 8. (Assuming the Power PMAC is in slot 0).

So I did as you suggested and got the exact same results. The lower pair values are in the AdcDemux.ResultLow[0] and AdcDemux.ResultLow[4] registers but the high pair values are not in AdcDemux.ResultHigh[0] or AdcDemux.ResultHigh[4], they just read 0. The connections are exactly the same so the values should be within a couple of bits of each other.

No, we were only testing #1, #5, #9, and #13 so we set the second convert code to $400 (for #5 and #13). #5 works correctly but we do not get #9 or #13 on the high element. We already have the base addresses set to $B00000. Even if the second convert code were wrong, the first one should have given us #9. (Forgot to mention, I already set AdcDemux.Address[1] = $B00000 as well.) When I get a chance (tomorrow), I will try setting them all as suggested but I can't see how that would make a difference.

We're having problems accessing data from the upper channels (9-16) of our ACC36E. Our board is at $B00000 so we've set up the following: AdcDemux.Address[0] = $B00000; AdcDemux.ConvertCode[0] = 0; AdcDemux.ConvertCode[1] = $400; AdcDemux.Enable = 2 AdcDemux.ResultLow[0] does contain result {Analog In #1} AdcDemux.ResultLow[1] does contain result {Analog In #5} AdcDemux.ResultHigh[0] should contain result but doesn't {Analog In #9} AdcDemux.ResultHigh[1] should contain result but doesn't {Analog In #13} We're reading a unipolar device between pins 1 & 9 using the voltage out between pins 7 & 6. Since all four connectors are the same, we moved the device around to each spot to test the values. The values for 1 and 4 are just as expected but we do not seem to get anything from 9 and 13. After setting Acc36E[1].ConvertCode=0, I also looked at Acc36E[1].ADCuLow (for #1) when the data showed ready and it was correct but Acc36E[1].ADCuHigh (for #9) again showed nothing. Did I miss a step or something? What would make the Low registers work and not the High ones?

Thanks, I did find that. The "Command" function is hard to find in any documentation. I found it in a document on Manually Scheduling Threads in Power PMAC.

I can't figure out how to call a motion program from a c program. I'm trying to cyclically run a motion program and then rest for a period. Is there an easy way to do this.

Hopefully, we are doing both. That is our current goal.

Can you use the PPMAC_INPUT and PPMAC_OUT blocks to access structures in the shared memory or do you have to use one for each element. I suspect the later because the support for passing of structures in SIMULINK seems to only have been implemented after version 7.6 (R2010b). It's just a pain to have to place a symbol for every element in the interface. Also, I'm not sure if it has been fixed yet but the version of the DELTATAU PPMAC Library which we have has PPAMC_INPUT (instead of PPMAC_INPUT) --obviously not important.

I was wondering if there is any bug-tracking database for the Power PMAC firmware and OS. For the project on which I am working, we have to closely track 3rd party software/firmware for version identification, known issues, and control. For control of the software, the issue is quite easy using the backup utilities for the Power PMAC but, for issue tracking, the solution is not so clear. I also seem to have a problem when running a full backup of the Power PMAC. It reports "Unable to save version info. This may be a problem when restoring this configuration. Do you still want to backup configuration?" This can be a major problem later on when we want to ensure that all of our systems have the same configuration.

Can any of the CanOpen versions be used to run raw CanBus communications or does the CanOpen layer have to be included?

No, it's okay. I will just use one of the Ethernet ports. But I guess you are telling me that I can use the RS232 port as an IDE or terminal connection? Actually, just found out about the ACC-72E. We may be able to do everything using a CanOpen system. The card isn't easy to find from the Delta Tau sight without knowing it exists. I was trying hard to find some sort of communications card and additional communications function to another card.

We're looking at using a RS422 to ethernet adapter to bring in the digital data we need. But, is it possible to use the USB port to connect to the Power UMAC CPU via telnet or the Power PMAC Suite software?

Is there anyway to utilize one of the USB ports (probably the USB 1 port) to input real-time data for use in the motion control system and therefore minimize the latency down to the 5ms ball park. It would appear that you can tweak the standard Linux RT to do it but I'm not clear on weather you can do it on the Delta Tau version since the documentation implies that only the Power PMAC tasks are "foreground" and that the other tasks are part of the GPOS and therefore lower-priority background tasks. I planned to use the ethernet to output telemetry in real-time and need a serial input portal to read data with less than 10ms latency. Before I go too far down this path, I wanted to confirm that it is even possible.