leandro.martins

The command should be cmd"\% %d",Percentage or cmd"%% %d",Percentage

I have found this disclaimer at the header of the gplib.h: /// \file gplib.h /// /// These functions are for use as an API for linux "C" APPs. /// \warning They are NOT available to user written real time "C" PLCs. Therefore, it looks that it's not possible to use the Command() in the Realtime Routines. I couldn't find anything with the same function of the online command "run" in the rtpmacapi. There is a function for cheching the CS status though. //------------------------------------------------------------- /// Returns enum of Coord Program Status /// /// \param[in] num - number /// \return enum progstatus enum progstatus CoordStatus(int num); My impression is that the C code generation is intended only for control loops purposes, not general logic. Sorry for not being able to help more.

The best thing would be consult the PowerPMAC C Help documentation It is attached into this another topic Probably this is the function that you are looking for //----------------------------------------------------------------------------------------------- /// Sends a command to the Pmac Command Processor /// /// Previous modal commands will be retained /// The input string is converted from symbolic to PMAC compatible commands and variables /// \param[in] *pinstr - ptr to PMAC input string /// \return 0 == OK, - == error number int Command (char *pinstr); or //----------------------------------------------------------------------------------------------- /// Sends a command to the Pmac Command Processor /// /// Previous modal commands aren't retained, thus the function is Thread Safe /// The input string is converted from symbolic to PMAC compatible commands and variables /// \param[in] *pinstr - ptr to PMAC input string /// \return 0 == OK, - == error number int CommandTS (char *pinstr);

In my opinion your plc is doing exactly the same thing if you set Motor[1].pDac =ECAT[0].IO[1].Data Motor[1].DacBias = 100 but your plc is being executed in a different task, with a different interruption. I assume that can make the motor to use the ECAT[0].IO[1].Data before the offset being applied. My best suggestion would be changing the motion program to open prog1 f(50+Q1) x300 x0 close being possible to use the Coord[x].Q[1] as your veloffset. As that isn't an option, I don't think that I have more suggestions. I hope someone else can help you.

The simplest way of doing that should be using the "%{constant}" online command, which overrides the motion program time-base. In that way you can increase up to two times the velocity described in motion program, sending via terminal the command %200 To return to default time-base %100 If your application really needs as an offset, and the relation between Motor[x].ServoOut and the velocity is well-known, probably you can use the the variable veloffset in Motor[x].DacBias.

I have used the MATLAB library only on older version, so just a guess: Is this the "DeltaTau" menu that you're looking for, by any chance? In other versions it used to be next to the "C code", but I assume that changes in the simulink layout along the versions might be making the "DeltaTau" menu to be placed in an awkward place.

Hi Martin89, Is it possible to try the IDE troubleshooter? Right-click on Motor1 > Troubleshooters > Motor Report. Also it might worth to have a look in the file using any text editor, to see if there is any obvious issue. Maybe that can give an idea of any unexpected value.

I have a similar issues when I try to download a project saved in a drive different (a network drive in my case) from the one where the IDE is installed. The problem happens at version 4.6.0.14. I didn't have the opportunity to check if I can reproduce that is the latest IDE release though. Also, I should say that I don't have admin permission in the PC, so cannot test if it's a windows permission issue.

The latest Matlab version supported by the PowerPMAC IDE 4.6.0.14 is the 2020b. You can check all the supported versions on the path: C:\DeltaTau\PowerPMAC\4\IDE\MATLAB Component Another option would be checking if there were any updates about Matlab support on the latest IDE release.

Not much related, but it might be interesting to add for discussion. Recently I have faced some differences on Sys.Cdata[i] structure between different firmware versions. I can't say if the difference is due to firmware version, or is something more intrinsic to the cpu (since the PowerPC endianess diverge from the ARM). While in fw 2.5.0.4 the Sys.Udata[0] points to the same region of Sys.Cdata[3], in fw 2.7.1.0 Sys.Udata[0] points to the same location of Sys.Cdata[0]. About the roll over, I have tested and both of the versions presented the same behaviour that Dave described.

I can't remember if I got that message, but when I had issues opening the tune and gather tools, it was due to the Windows firewall. It might worth to have a look if the DeltaTauGatherProgram is an allowed app in Windows Defender Firewall, for the type of network that you are using to connect with the Power PMAC.

For the Sys.Udata[x] stucture this seems to work ptr pUdata(8)->u.user:$24.0.32+ // OR u.user:36.0.32+ // OR u.user:36+ ,if not using offset or setting the maximum size pUdata(0),8 M8192=0 M8193=0 M8194=0 M8195=0 M8196=0 M8197=0 M8198=0 M8199=0 M8192,8-> M8192->u.user:$24 M8193->u.user:$28 M8194->u.user:$2c M8195->u.user:$30 M8196->u.user:$34 M8197->u.user:$38 M8198->u.user:$3c M8199->u.user:$40 Sys.Udata[9]=9,10,11,12,13,14,15,16 pUdata(0),8 M8192=9 M8193=10 M8194=11 M8195=12 M8196=13 M8197=14 M8198=15 M8199=16

As just an educated guess, to set correctly the Motor[x].HomePos in that case, it's necessary to consider the current HomePos. Since the queried position on the position window is equivalent to Motor[x].ActPos-Motor[x].HomePos, so setting a position to zero should look like something like Motor[x].HomePos={commanded position}-Motor[x].HomePos As far as I know, the PSET also exists for PowerPMAC, that I suppose that does exactly the same operation manipulating the HomePos. I hope that helps.

Hi @DaveBarnett, What I know about that kind of syntax is this equivalence Sys.Udata[0] // u.user:0 Sys.Udata[1] // u.user:4 Sys.Udata[2] // u.user:8 Sys.Udata[3] // u.user:c The same applies for Idata, Fdata and Ddata (respecting the data structure organization) The u.user structure follows something like this u.user:{Beginning of that memory}:{Number of bits shifted}:{Number of bits}. Haven't been able to find the purpose of the "+" on your example, maybe is something specific for the BufIO. I'm also interested if there is anyway more elegant of handling those structures.

I couldn't spot any kind of error in your code. What is the behaviour that you are obtaining?

If I recall correctly, the .pmh file is generated only if you use tunable parameters. Is that your case? Are the .txt files being generated?

Indeed, the firewall was blamed. For anyone that might have the same issue, the firewall configuration can be checked in: Control Panel > System and Security > Windows Defender Firewall > Allowed applications Here, it should exist an entry for DeltaTauGatherProgram, if there isn't it can be added with "Allow another app" option and pointing the path that should be something like : C:\DeltaTau\PowerPMAC\4\IDE\PlotControl\DeltaTauGatherProgram Notice that the permission is defined for each: Domain, Private and Public.

It might be related with the issue described in: My suggestion would be: try to query Sys.RtIntErrorCtr to check its value, then set it to 0, and check it again. If possible repeat the same steps without using the IDE (ssh'ing the controller, and opening a gpascii connection) If the error is not recurrent, then it is possible to include in the PLC that runs after a power-on/reset, setting it to 0.

Hi James, Have you tried to check the "Legacy Mode", under the "Gather options" in the plot window?

Since you want a high-frequency pulse generator, it might help to use PhaseCtrl = 8. In that way, I suppose that with your servo routine being executed at the phase interruption, obtaining the same effect as a motor being commuted (without closing the current loop). If I'm right in supposing that, you will need to : Consider the Sys.PhaseOverServoTime in your servo routine. Set your feedback properly to this mode by configuring the Motor[x].pPhaseEnc/PhaseEncLeftShift/PhaseEncRightShift I hope that helps.

You're right, I've misread as 0x0b1111. Maybe you can do this using a static variable. I've never tried to use in a Real-time routine on powerpmac, so, I'm not sure if work. If you want to try, it would be something like this: double custom_pfm(struct MotorData *Mptr) { // Auxiliar variables double servo_out, servo_period, pfm_clk_freq, pos_error; static double servo_out_nxt = 0; unsigned int pfm_clock_div; volatile GateArray3 *Gate3; // If closed loop is enabled if (Mptr->ClosedLoop == 1) { servo_out = servo_out_nxt; // Calculates position error relative to JogPos pos_error = ((Mptr->JogPos) - (Mptr->HomePos)) - ((Mptr->ActPos) - (Mptr->HomePos)); // Calculates PFM clock frequency Gate3 = GetGate3MemPtr(0); pfm_clock_div = ((Gate3->HardwareClockCtrl) >> 16) & 0b1111; pfm_clk_freq = 100e6 / pow(2, pfm_clock_div); // Calculates Servo Period servo_period = (pshm->ServoPeriod) / 1000; // Calculates Servo Out servo_out_nxt = ((pos_error / servo_period) * 65536) / pfm_clk_freq; // Saturates at 5 MHz if (servo_out_nxt > 3276.8) { return 3276.8; } else if (servo_out_nxt < -3276.8) { return -3276.8; } // Return Servo Out return servo_out; } else { servo_out_nxt = 0; } // Return 0 if closed loop is not enabled return 0.0; }

Hello Rafael, Are you getting the expected value in pfm_clock_div? It's not clear to me why you are masking with 0b1111, instead of getting the first 4 bits (0xF) after the right-shift getting the bits 16-19 of HardwareClockCtrl.

2) I vaguely know how Sys.IData[x]/Sys.UData[x] works. Both of the elements points to the same memory address, being just interpreted in different format depending on what element you consult. Negative values are stored in two's complement, so for converting you'll need to invert all of bits of the integer, then add 1. When you query for Sys.Udata[x], the bits in that address would be interpreted as an unsigned integer: bit0*2^0 + bit1*2^1+bit2*2^2...+bit31*2^31 e.g. Sys.IData[0]=1 Sys.IData[1]=-1 Then Sys.UHex[0]=$1 Sys.UData[0]=1 Sys.UHex[1] = $ffffffff // Inverting $00000001 --> $fffffffe, then add 1 --> $ffffffff Sys.UData[1] = 4294967294 I don't know if that was exactly the question, but I hope that helps. I'm sure that Gregs can complement my answer if necessary.

Hello @xuantran, I believe that commanding out0 or j/ in any of the motors should clear the fault when the input signal is in a healthy signal. You can test that doing the following Sys.pAbortAll=Sys.Idata[10].a // Sys.Idata[10] as Abort input Sys.Idata[10]=1 // Abort State Sys.Idata[10]=0 // Healthy State #1j/ // Clears Sys.AbortAll In case that you don't want to use a real motor, you can use the Motor[0] for that, being necessary to set Motor[0].ServoCtrl=1. [EDIT] Complementing the answer, as described in the Software Reference Manual, the "abort all" state is cleared after the abort input is 0, and any motor or coordinate system is commanded As you have a NC switch, depending on how it's connected it might be necessary to invert the logic: ideally changing the electrical connections; or by software. One way of doing by software would be something like this: #define _AbortInput Gate3[0].GpioData[0].a Sys.pAbortAll = Sys.Idata[10].a open plc 1 if (_AbortInput) {Sys.Idata[10] = 0} else {Sys.Idata[10] = 1} close

Thank you for checking Steve. We're already thinking in keep the submodules in a different location and automate the process to include in the project structure. Anyway, if your permit me, I'd like to let this as suggestion to be considered for future IDE releases. I think it could be pretty useful, and my ingenuity make me think that it wouldn't be a very hard to recursively generate the "pp_proj.ini" from a project with more levels then now. But I also understand if that doesn't fit in the roadmap. Thank you again