leandro.martins
-
Posts
88 -
Joined
-
Days Won
6
Content Type
Profiles
Forums
Events
Downloads
Posts posted by leandro.martins
-
-
I have noticed that in the rtpmaclib.h there is vcross function for the cross product operation between vectors
As the vcopy, vmadd and vscale can be used also in the script language, I would like to know if in fact the vcross isn't available for script language, or if it's just not documented.
Thanks -
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 setMotor[1].pDac =ECAT[0].IO[1].Data Motor[1].DacBias = 100but 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 toopen prog1 f(50+Q1) x300 x0 closebeing 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.-
1
-
-
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-
1
-
-
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.
-
1
-
-
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:cThe 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.
-
22 hours ago, RafaelFalcaro said:
Yes, the pfm_clock_div value is correct. Making the mask with 0b1111 or 0xF don't give the same result?
You're right, I've misread as 0x0b1111.
15 hours ago, RafaelFalcaro said:Or even, a register that configures the controller to only use the new return value of the servo loop in the next Servo Interrupt?
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]=-1Then
Sys.UHex[0]=$1 Sys.UData[0]=1 Sys.UHex[1] = $ffffffff // Inverting $00000001 --> $fffffffe, then add 1 --> $ffffffff Sys.UData[1] = 4294967294I 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.-
1
-
I'm looking for help about the rotation buffer!
in Power PMAC
Posted
Some things can interfere in F command (vector feedrate):
Have a look at "F{data}" section in the Software Reference Manual.