wehg

Thank you for your reply. I probably should have clarified that I'm not having any issues with loosing samples, only that I am limited by a finite amount of data based on the gather buffer size. Currently I am reading the available gather buffer size using gather.enable=1, then setting Gather.MaxSamples = Gather.MaxLines. For what I would like to do, based on the Manual, I'm most interested in using gather.enable=3. I guess the question becomes: When using gather.enable=3, is the gather_csv utility applicable or usable? And if so, how do you use it in combination with gather.enable=3?

Hello, I'm trying to accomplish the same functionality as George regarding streaming gathered data to a file. I can successfully gather data to the gather buffer using Gather.Enable=2, and then write the gathered data to a file at gather completion using the gather_csv -u utility. This works fine, but is limited by the size of the gather buffer. What I am trying to do is stream the gathered data to a file in rotary fashion, so that I am not limited by the gather buffer size. So far, I have not been successful with this rotary method. Can you share an example of how to do this? I'm using an ARM cpu with firmware 2.6.0.1.

I have an application where a motion program is primarily executing in incremental mode. It is desired to have the ability to program a stop condition, jog the axes to a new location, and then resume program execution on the next line/block. (Not jog back to the previous programmed position before continuing.) I'm using the 'pause' command to stop execution, then jogging to a new location, and issuing a 'pmatch' command prior to attempting to resume execution with the 'run' command. This causes an 'error#46 COORD JOGGED OUT OF POSITION'. Lookahead is active. Any suggestions as to how to implement this functionality properly? Thanks

I have two different applications/projects where the Coord[].TimerEnabled move timer status is behaving differently. In the first application if I feedhold a move using quick stop (lh\) or 'hold' command, the move stops as expected and the move timer status goes to 0, which allows the in-position status to go true, and all is well. In the second application, if I feedhold a move using the same commands, the move stops as expected, but the move timer status remains 1, which prevents the in-position status from going true. Any thoughts on what might cause this difference in behavior? My real issue falls in the resulting difference in 'in-position' behavior. In both cases the move execution resumes fine with a 'run' command. As a side note, if in the second application the move is stopped with a 'pause' command allowing the current move to finish, the move timer status goes to 0 as expected.

Thanks Steve, I think I can work with something similar.

Hello, Is there a convenient way to distinguish between a cold startup condition, versus a Build & Download of the project? We have some time related requirements that need to be monitored following a cold startup, but don't want them to be reset upon a Build & Download. Thanks

I'm using an ACC24E3 and trying to configure a stepper motor in the mode that the PPMAC User Manual refers to as 'second option': The second option is to feed back the pulse train for simulated feedback, but also to use an encoder for confirmation periodically. In the PMAC3-style IC, this can all be done in a single channel (it requires two channels on a PMAC2-style IC). From the Manual, my understanding is that setting Gate3.Chan[j].TimerMode = 3 is the key to freeing up the encoder channel input for the confirmation encoder input: To implement the second option, the pulse train must be fed back into the channel’s timer circuitry with Gate3.Chan[j].TimerMode set to 3. The Gate3.Chan[j].TimerA register will be used to close the simulated servo loop. The confirming encoder is fed into the channel’s encoder inputs, and Gate3.Chan[j].EncCtrl is set to a value from 0 to 7 (probably 3 or 7) to decode this signal. I would like to use the timer register as indicated above to avoid the sub-count interpolation. I have tried four different configurations listed below, and only two will successfully run the motor. It appears that unless Gate3[1].Chan[0].EncCtrl = 8, the motor will not run. In addition it appears that unless I have EncTable[].pEnc = Gate3[].Chan[].ServoCapt.a the motor will not run either. Am I missing something that needs to be set to select the pulse and direction mode, while allowing the encoder channel input to be configured for a quadrature encoder? I am using the file below to download the various configurations, and you will see from the comments the behavior that I see. Sys.WpKey=$aaaaaaaa; //Common Settings for all configurations below. Gate3[1].PfmClockDiv = 5; Gate3[1].EncClockDiv = 3; Gate3[1].Chan[0].OutFlagD = 1; Gate3[1].Chan[0].TimerMode = 3; Gate3[1].Chan[0].PfmWidth = 100; Gate3[1].Chan[0].OutputPol = 0; Gate3[1].Chan[0].PfmDirPol = 0; Gate3[1].Chan[0].OutputMode = 8; Gate3[1].Chan[0].PackOutData = 0; Gate3[1].Chan[0].PackInData = 0; Motor[11].pEnc=EncTable[13].a Motor[11].pEnc2=EncTable[13].a Motor[11].Servo.BreakPosErr=1.0 Motor[11].Servo.Kbreak=0 EncTable[13].index2=0; EncTable[13].index3=0; EncTable[13].index4=0; EncTable[13].index5=0; EncTable[13].MaxDelta=0; EncTable[13].ScaleFactor=0.00390625; //Configuration #1 //This configuration was kindly posted on the forum by another user, and runs //the motor fine. Unfortunately it doesn't support using the confirmation encoder. Gate3[1].Chan[0].EncCtrl = 8; EncTable[13].type=3; EncTable[13].index1=0; EncTable[13].pEnc=Gate3[1].Chan[0].ServoCapt.a; EncTable[13].pEnc1=Gate3[1].Chan[0].TimerA.a; //Configuration #2 //This was my attempt to configure from the User Manual 'Second Option' //information and settings, and allow use of the encoder channel //input for position confirmation only. //Motor does not run, oscillates/creeps real slow upon jog command, and //exceeds DAC limit setting. //Gate3[1].Chan[0].EncCtrl = 3; //EncTable[13].type=1; //EncTable[13].index1=8; //EncTable[13].pEnc=Gate3[1].Chan[0].TimerA.a; //EncTable[13].pEnc1=Sys.pushm; //Configuration #3 //This configuration is the same as #2, only changing the .EncCtrl = 8 //No Difference in motor behavior from #2. //Gate3[1].Chan[0].EncCtrl = 8; //EncTable[13].type=1; //EncTable[13].index1=8; //EncTable[13].pEnc=Gate3[1].Chan[0].TimerA.a; //EncTable[13].pEnc1=Sys.pushm; //Configuration #4 //This was a trial to configure from the User Manual 1/T extension method //using ServoCapt as source register. This the runs the motor fine also, //but does not support use of the encoder channel for the confirmation encoder. //Gate3[1].Chan[0].EncCtrl = 8; //EncTable[13].type=1; //EncTable[13].index1=0; //EncTable[13].pEnc=Gate3[1].Chan[0].ServoCapt.a; //EncTable[13].pEnc1=Sys.pushm; Sys.WpKey=0;

Is there any documentation available that might be helpful regarding communicating through Modbus with PPMAC. In this case the device is a stepper motor indexer. Thanks,

I had a similar problem to this just the other day after a routine power down and power up condition. I was receiving the error where it could not find the pp_hardware.sym file. Upon further examination I noticed that in the /var/ftp/usrflash directory, the only directory left was 'Project'. Both 'Database' and 'Temp' had disappeared. In my case, I just recreated the directories and copied in the directory contents from a like running PPMAC, and all was fine after that. It was the first time I had experienced this problem.

[quote='ScottB' pid='8130' dateline='1437565026'] I'm not sure I understand, I thought standard C ignored whitespace. IF ((M1 == 0) && (M2==0)) is supposed to be identical to: IF ((M1 == 0) && (M2 == 0) ) and is identical to: IF ((M1 == 0) && (M2 == 0)) This is not the case in Power PMAC script (although it was in Turbo!). If this is never going to be "fixed", then is there at least some type of line continuation characters that we can use to break up extremely long lines? [/quote] I use the '\' on occasion in script for line continuation and it seems to work fine.

The settings are in pp_startup, so I tried disabling, issuing commands manually, and re-enabling. No difference. This is what I've learned today: Jeff had mentioned earlier today that he had previously had Muxio functioning with 2.0.0.1 firmware. I updated from 1.6.1.1 to 2.0.0.1 and the Muxio immediately started functioning normally. Next I updated from 2.0.0.1 to 2.0.2.14, at it immediately broke. What I'm currently seeing is that inputs are changing, but they are not as expected. As an example, our feedrate override switch is looking at 4 bits of a 32 bit word, in most cases (not all) of changing the switch position, the value changes, but none of the switch positions reflect the correct value. Outputs are now changing state, but outputs that should be unrelated to specific inputs, are turning on/off when the unrelated input changes state. It acts like something has either changed in the addressing or data transfer. I've tried slowing the clock period and Update period way down from your settings, and it seems to have no affect. In case it's of help, in summary the sequence I've been through to break and un-break things: updated from 1.6.1.1 to 2.0.2.14 broke Muxio. reverting back to 1.6.1.1 did not restore to functional. updated from 1.6.1.1 to 2.0.0.1 fixed the problem. updated from 2.0.0.1 to 2.0.2.14 broke it again.

I wasn't able to successfully copy the uImage file from the PC to PPMAC memory using this post. I put the tfpt server and associated files on a shared folder on the PC with read/write permissions. I configured the serial communications for 115200, 8bit, Parity None, Stop Bits 1, Flow Control none. I've verified the batch file paths are correct, and triple checked the IP addresses, and continually get a Timeout error just showing T's and no ####... I was able to download the uImage from this post using the IDE Kernel Update tab, then followed with 1.6.1.1 firmware download. I also have tried extracting the 1.6.1.1 uImage from the 1.6.1.1.deb package, and downloaded it through the IDE as well, followed by again downloading the 1.6.1.1 firmware. Neither sequence has brought the Muxio back alive, with again trying toggling the Muxio.Enable. Am I safe to assume that loading the kernel through the IDE has the same affect as loading it via the tftp server? (The available memory check as referred to by an alternate post, indicated PPMAC had adequate memory.) If so, I'm not sure how best to proceed?

The only setting I see different is Gate2[0].PartData[1]=$FFF1, but this is the same setting of alternate machines that are functioning fine. It still seems like something is corrupt on the CPU card, as I can take another CPU card from another machine with the same firmware, do a $$$*** reset, load the project, and all works fine. Our muxIO setup is included in the project.

Thanks for the reply. I tried toggling the MuxIO.Enable, No difference. MuxIO Settings: MuxIO.ClockPeriod = 8; //8usec (125Khz) clock rate MuxIO.InBit = 8; MuxIO.OutBit = 16; MuxIO.pIn = Gate2[0].MuxData.a; //Input register pointer MuxIO.pOut = Gate2[0].MuxData.a; //Output register pointer MuxIO.UpdatePeriod = 5; //5 msec scan rate MuxIO.PortA[2].Dir = 0; //1st PortA addr are inputs MuxIO.PortA[4].Dir = 0; //2nd PortA addr are inputs MuxIO.PortB[2].Dir = 1; //1st PortB addr are outputs MuxIO.PortB[4].Dir = 1; //2nd PortB addr are outputs MuxIO.PortA[2].Enable = 1; //Enable 1st PortA addr MuxIO.PortA[4].Enable = 1; //Enable 2nd PortA addr MuxIO.PortB[2].Enable = 1; //Enable 1st PortB addr MuxIO.PortB[4].Enable = 1; //Enable 2nd PortB addr MuxIO.Enable = 1; //Enable the firmware Mux IO

Hello, I started with a fully functional machine, with the desire to update the firmware from 1.6.1.1 to 2.02.14 (460EX). I first created a recovery disk 'Power PMAC Complete' using the IDE. I next installed the new firmware after normal $$$***, save, etc. We are using MuxIO through ACC5E, and with the new firmware the MuxIO would not function. In the essence of time, decided to revert back to the 1.6.1.1 firmware using the recovery disk I had created, as well as trying to load the firmware and project manually. In either case, the MuxIO will no longer function. The system is configured with MuxIO.PortA[].Data as inputs, and MuxIO.PortB[].Data as outputs. I see no input data from hardware. I can write to output data, but it's not getting to the hardware. Two questions: A. Apparently something is not getting restored, so how can I get back to original state? B. Has anyone used MuxIO through ACC5E, with the current 2.0.2.14 Firmware, and if so is there something that I need change to make compatible. Thank you

The Gather.Enable setting appears to support operating the gather buffer in a rotary fashion. Is there a way to use the gather_csv utility to stream the data out to a file, before the original data gets overwritten when it wraps around after filling the buffer? Thanks

I have a ballscrew driven stage that utilizes both linear and rotary encoder feedback devices, controlled by PPMAC. Both encoders are interfaced to an ACC24E3. The position loop linear encoder is sin/cos, has a physical resolution of 1.22e-6 mm after 16384 interpolation, and connects to the standard encoder channel input. The velocity loop rotary encoder is quadrature, has a physical resolution of 5.0e-4 mm after 4x interpolation, and connects to the U,W channels of the supplemental quadrature interface. How should the EncTable[].ScaleFactor for each encoder be configured to match the effective resolutions to the motor? Thanks for the help.

I too have experienced the same issue when updating from previous 1.5 firmware and IDE to versions 1.6, that every time I open the IDE it tells me the currently loaded project differs from what is loaded on PPMAC. I have tried Sina's procedure to correct the issue twice now, to no avail. Are there any other suggestions? I am currently using Firmware 1.6.0.30 and IDE 1.6.0.109. I updated from Firmware 1.5.8.245 and IDE 1.6.0.41 4/25/13. Thanks,

In a Power PMAC system, how do I read a quadrature encoder on the Acc5e handwheel port? Thanks

When I query actual positions using pread, in regards to axis compensation, am I correct in assuming that I am reading the corrected position and not the raw position? Thanks

Curt, Will the Gate3[].Chan[].LossStatus still be valid for encoder fault detection in the condition described above? Thanx

Thanks you!

Hello, Is there a way that I can issue a 'Quick Stop' command from a Cplc. The compiler doesn't seem to allow: Command ("&1\"); , and if I understand correctly the 'Direct Commands' are only allowed from the script environment? Yes/no? Thanks, Wehg

OK, thanks.