JeffLowe

Charles look at I47..50, then memory stating at x:$06001A. This for using DPR automatic data reporting to reduce command buffer traffic. I am hoping you have some example code on this because I need to implement this for a multithreading application I have where I am doing background polling for position with foreground control/data transfer for motion.

Thank you for this update Charles. In the interim while we wait for the pipeline to fill up again, can you give me an example of how to set up MUXIO with the ACC5E3?

What are our alternatives to address the current unavailability of the ACC 5E. The Acc5E3 appears to address the dual handwheel encoder inputs, and it appears that the 16 bit I/O channel will work for emulating the JMux connector, however, there is no 32 bit J-I/O. Is the ACC-14E still available and does it work with the PowerPMAC? Are there any more effective solutions?

Any schedule for the Macro Option for the Power Clipper?

We purchased our probing macros from Renishaw.

I have been trying to scale the internal 32 bit integer DAC values to a +/- 2^15 range. Scale factors less than unity are plotting zero values. I have tried Scale = 1/65536, 0.0000152587890625. adding div to the process and inserting 65536 after it, and adding * 0.0000152587890625 to the process. Prior to adding the process or scale factor the values are in the 1e9 range, afterward are flat line zero. Multiplication with a scale factor of 2 does indeed double the plot amplitude, but in this case I need to reduce the values to a correct nominal scale. Is this a feature?

For our multiaxis jog until trigger we set the Motor[x].ProgJogPos set to the appropriate end targets then use jog1,3=*^0;

Are there examples for calculating this, given the amplifier transconductance gain, motor Kt, and stage mass/inertia? Our systems are fluid film bearing with almost no friction or damping, and it is difficult to get away from gravitational biases. The routines in the auto tuning feature in the IDE rely on open loop moves, and aside from the difficutly in keeping the stages still long enough, suffer from insufficient resolution. I am hoping that DT has a closed loop solution based on desired acc, act acc and dac output. While I am on this subject the tuning limitations in the tuning routine often do not allow enough time to conduct a meaningful move. The present 1 second limitation for step, and two second for parabolic don't come any near long enough for high inertia direct drive positioning. Thanks,

What documentation exists for the autocorrecting interpolator? Is it simply a plug and play, or is there more? Also, How does the input bandwidth compare to that of the ACC24e3?

What documentation exists for the autocorrecting interpolator? Is it simply a plug and play, or is there more? Also, How does the input bandwidth compare to that of the ACC24e3?

We use braking on a direct drive rotary axis and our approach is once the axis is in position to set: Motor[x].MaxInt=0; Motor[x].MaxDac= (some small value, enough to keep from drifting) Activate Brake dwell enough time to engage Motor[x].MaxDac=0 ; At this point the motor is still closed loop, but not applying any power to the motor. This works well with linear drives, but you may still have some heat with a 50% modulated PWM. Delta Tau's new TriLevel PWM could help with this(?). To reengage drive simply reverse the process, perhaps with a ramp for the MaxInt up in case there has been some drift. Also, I would leave the FatalFeLimit in place to serve as a position loss detector.

We use braking on a direct drive rotary axis and our approach is once the axis is in position to set: Motor[x].MaxInt=0; Motor[x].MaxDac= (some small value, enough to keep from drifting) Activate Brake dwell enough time to engage Motor[x].MaxDac=0 ; At this point the motor is still closed loop, but not applying any power to the motor. This works well with linear drives, but you may still have some heat with a 50% modulated PWM. Delta Tau's new TriLevel PWM could help with this(?). To reengage drive simply reverse the process, perhaps with a ramp for the MaxInt up in case there has been some drift. Also, I would leave the FatalFeLimit in place to serve as a position loss detector.

Or would you rather receive bug reports here? I have several open and have not received any responses.

Or would you rather receive bug reports here? I have several open and have not received any responses.

The 1.6.x firmware adds this new system variable which makes for more robust applications, however it also breaks the tuning plot routines, and Servo Analyzer. Setting Sys.NoShortCmds will allow these to function normally.

The PIP loops of the PMAC do a good job of controlling many different kinds of loops including temperature. Signal conditioning modules from various sources can convert RDT, Thermocouple, or Thermistor to 0-10V which can be brought in through the ACC28E. For outputs, simple bang-bang could be done under plc control using an I/O bit and an SSR. Moving up a bit in sophistication, you could use the DAC outputs of a motor channel to control a proportional SSR as well. Old school N-Z tuning methods work well, Probably will want to use servo cycle extension Ix60 to slow the servo update down to 10-20x the response time of the system.

If there are going to be any issues I believe it will be in getting Windows NT to recognize the PMAC card. Have you tried seeing if the Turbo PMAC PCI card is even going to be recognized by the OS? IF NT does not automatically pick up the card, the issue is going to be porting your system to a newer OS which will mean updating to a newer communications library like PCommServer.

The PMAC itself will be no problem, however any code running on the PC that communicates with the PMAC will need to be examined. What programs are running on the PC that communicate with the Turbo PMAC?

Thanks Steve, this worked great. I used Altap Salamander to extract the uImage from the latest powerpmac.deb. The only thing that is not real clear in the procedure is the ip addresses. Some clarification in the procedure that specifies using the IP of the PPMAC and the Host (server) would be helpful, but no worries.

We were upgrading firmware from 1.5.x to 1.6.x and the IDE hung then crashed. Restarts of the PPMAC just drop into u-boot, throwing a kernel image error. Is there a way to load this on a stick and get the kernel to restore, and where would I find an image for it. I tried the stick with PowerPmacFirmwareInstall folder with the .deb file in it, but the pmac sould not get past the kernel image not found. Thanks for any help here.

We are having problems with corrupt dual port ram read data. The diagnostic supplied in PEWin is only Write from PMAC/ Verify on PC. I need to operate in the other direction, ie Write from PC/Verify on PMAC. Ideally this test would be able to do $5555, $AAAA, Walking zero, walking ones and checkerboard. Has anybody put together such a diagnostic?

A little follow on: Digging in I have found that bit 22 of x:$3120 gets set when the gather buffer wraps. This bit is the cause of the huge number buffer start which results in an a parent gather count in the bazillions. Also, if bit 22 is set the on line command List Gather returns an ERR003 Data error or unrecognized command. By clearing bit 22 to zero (or subtracting $400000) the list gather function works. This also works with the Plot Pro2, although the after setting the gather items, and the define gather in plot pro, it will be necessary to go to the terminal, set I5000=1 for ram wrapping, and define a fixed length gather buffer (def gat 10000). Gathering can be started from here as well. The CMD"End Gat" can then be inserted in a plc, in my case an alarm plc, and when the event occurs gathering is halted. Clear bit 22, and the data can then be uploaded and plotted. Suggestion: Add detecting and clearing of this bit to UINT CPmac::GetNumGatherSamples( DWORD dwDevice ) in PCommServer.

We are trying to gather the history leading up to an event by setting the gather buffer to loop in ram and sending an endg when the event occurs. I know the plot utility does not support this, but it turns out that calls to the .CollectGatherData method in pcomserver also causes the same errors ( Windows cannot allocate a bazillion bytes). The root cause of this appears to be in the GetNumGatherSamples function in PcommServer where the routine reads x:$3120 as the start, and Y:$3120 as the end. Once the gather wraps the beginning is larger than the end and of course it returns a negative number. Internally the beginning and end are longs, but in the calculation they are cast as an int which truncates the beginning of the twos complement long. The result is some undefined large number of data samples ( a bazillion or so). Is there any fix to the pcomserver, and/or are there other variables that point to the location of the gather buffer, or other way that I can find the head/tail/size so I can upload the data using other methods?

The turbo PMAC has M168->X:$0000BF,8,16,S ; #1 Filter Output (16-bit DAC bits) which is a usefull node forforce loops and dancer arm type controls. What is the PPmac equivalent of this node? Thanks.

We are implementing a G31 move and need to set multiple axes into motion until a trigger is observed. Because we are using kinematics, the normal move until triggers within a motion program cannot work. The alternative is to do this with Jog1=1234^0 jog2=12^0 type commands. My problem is that if these are issued from a motion program, the first axis will move, and after reaching the end or trigger, the second axis will start it's move. It is required that these be near to concurrent. Executing this with a CX from the command line works fine. Writing a separate plc for the sole purpose of picking up the data from my motion and executing these jog moves seems less than desirable, and I am looking for alternatives. For testing I have been trying simple incremental jogs. Inserting CX pmatch #1jog:5 #3jog:5 did not build. Using: cmd"CX pmatch #1jog:5 #3jog:5"; builds fine, but does not initiate any motion. Any suggestions on other things to try, or should I just bite the bullet and pass everything through common variables and execute it based on a flag.