[Built-in Matrix Operations in C]

You can, of course, use all PMAC script math functions in the script portion of the Kinematic routines, but not in C.

 

However, the Power PMAC C-API has vector/matrix math functions that you can use in your PMAC C-programming (as in “CfromScript()”).

 

The descriptions for the Power PMAC C-API functions are in the “Help” of the IDE. But note that it wouldn’t “import” properly in versions 3&4.

 

This can be added manually, though. The files are at this “ftp” location with an instructional PDF document:

"ftp://support.deltatau.com/DT-USA/milici/PPMAC%20IDE/Help%20Files/"

 

Good to know, that's really useful.

 

Thank you!

[Built-in Matrix Operations in C]

Hello, I would like to know if is it possible to use the built-in linear algebra operations in a C script for the Kinematics.

 

For example, to use the Newton-Raphson method to solve kinematics I would need to calculate matrix multiplications and matrix inversion. Using CfromScript(), is it possible to use the built-in matrix operations? Or I would have to create my own matrix operations functions (or try installing an external library like C BLAS)? If it's possible, is there any example available?

[Low Current Motors with 5A/15 A Amplifier - Safety]

Hi Matheus,

 

You have already discovered that it is not easy to configure small motors on big amplifiers! It is possible to do it but it requires care. We have many customers who have made it work.

 

I suggest putting a fuse in each phase to provide protection if you have an incorrect setting.

 

Start with a very small value for Motor[x].Iigain. Try 0.01 and a current step of 100 bits and see what happens. Make sure that the current loop is controlling properly without a massive overshoot.

 

I know all the units you have are 5/15A versions but there are also smaller versions (0.25/0.75 and 1/3) available if you need to run a lot of small motors.

 

Tony Jacobs (Faraday Motion Controls)

 

Thank you by your advice.

 

I had success driving 150 mA and 400 mA motors before, so it should not be a problem.

 

But this time we suspect of the combination of low current and low inductance, that may cause higher current ripples.

 

Do you think increasing PWM frequency can help in this case? The currently frequency is 20 kHz.

[Low Current Motors with 5A/15 A Amplifier - Safety]

Hello, I have to drive a low current two phase stepper motor using the 5/15A PWM Amplifier.

 

The motor has a RMS current per phase equal to 220 mA. The Resistance is 7.4 ohms and the inductance is 2.1 mH.

 

I would like to know if there are recommendations about a safe Current Loop Tuning, talking about the starting PI gains and I2T configuration.

 

I'm using:

 

GLOBAL Ch6MaxAdc = 33.85;

GLOBAL Ch6RmsContCur = 0.17

GLOBAL Ch6RmsPeakCur = 2 *(Ch6RmsContCur);

GLOBAL Ch6TimeAtPeak = 0.1;

 

Motor[6].MaxDac = Ch6RmsPeakCur * 40132.44 / Ch6MaxAdc

Motor[6].I2TSet = Ch6RmsContCur * 40132.44 / Ch6MaxAdc

Motor[6].I2tTrip = (POW(Motor[6].MaxDac,2) - POW(Motor[6].I2TSet,2)) * Ch6TimeAtPeak

Motor[6].IdCmd = Motor[6].I2TSet/2;

 

The Current Step Magnitude I want to use is 150 bits (same for Rough Phasing) (less than the I2TSet value).

 

I have already damaged a same model motor, so it's important to do the current tuning process in a safe way, considering that is a low current and low inductance motor, that might be fragile over possible current peaks.

 

Any sugestions about driving low current and low inductance motors with the 5/15A amplifier? Starting safe gains?

 

Any condition that would bypass the I2T set to consider using external fuses?

[HomePos Behaviour Using SSI Absolute Encoder]

What do you mean by capture position? I feel like I was misunderstanding your question. Looking back over, it sounds like you just mean the position displayed in the IDE after a $$$ or #4hmz. Is this correct? Maybe the HomePos value is changing, but the real question is why does my position look like nonsense after a $$$ or #4hmz?

 

This could easily mean the scale factors for ongoing vs power up positions don't match or a number of settings. I'd like to start with Motor[4].AbsPosFormat

 

Motor[4].AbsPosFormat looks a little funny. We normally say Motor[4].AbsPosFormat=$AABBCCDD and look at each byte individually

Motor[4].AbsPosFormat=$72001907

DD=$07=7 Read from first register starting at bit 7

CC=$19=25 Read a total of 25 bits

BB=$00=0 When reading remaining bits from second register, start at bit 0

AA=$72=114 Use a format of ????

AA should be 0-3 for signed/unsigned binary/grey code.

 

By captured position I mean ActPos - HomePos, that is the position we see in the IDE.

 

I'm using AA this way: First A as 7 because we have 25 bits of data, we need to shift 7 bits to the left to have it as MSBs, it can be done using the first A as indicated in the manual. The second A is set as 2 to get the conversion from gray code to unsigned binary. I even tried using $02 instead of $72, without this shift, but get the same results, sometimes it just goes to zero (both ActPos and HomePos goes zero).

 

The rest is exactly as you pointed.

 

I tried testing changes in PowerOnMode too, do you have a guess about this parameter? It's a stepper motor and I'm using hybrid mode. I would keep PowerOnMode as 2, but I tried other configurations.

[HomePos Behaviour Using SSI Absolute Encoder]

Even for an absolute serial encoder, your position comes from two sources.

Motor[x].Pos/ActPos is created by looking at the change in the number Enctable[n].pEnc points at since PMAC starts up (or since Motor[x].ServoCtrl was set =1). This is purely incremental and ignores the value on startup.

Homez/HMZ, reading the absolute encoder to set Motor[x].HomePos.

 

Yes, I understand that. But my problem is that if I move motor till a X in the capture position and then do a reset (using $$$ or in the source), the capture position that is read is different than it was before, without moving motor again.

 

I've tried working with the PowerOnMode and the AbsPosFormat, but with no success. And sometimes if I do a second reset after the first one, the capture pos values goes to zero, really strange behaviour.

[HomePos Behaviour Using SSI Absolute Encoder]

Motor position variables tend to be position relative to the Motor's power on position. This is true for at least Motor[x].Pos, Motor[x].ActPos, Motor[x].DesPos.

 

To get the (compensated encoder) position relative to home, you would take Motor[x].ActPos-Motor[x].HomePos.

 

On a HOMEZ or HMZ, PMAC does not change the value of Motor[x].ActPos, but instead changes Motor[x].HomePos based on the captured absolute position so that Motor[x].ActPos-Motor[x].HomePos is your captured absolute position. This means the Captured position should change and HomePos should be the power on position.

 

Right, ActPos is relative to the absolute power on position, so it should be an absolute position when using an absolute encoder. The Capture Pos depends on the ActPos value and the HomePos value, shouldn't the HomePos position always be absolute 0 as reference position for absolute encoder? It's absolute, the zero is known, after a reset the encoder reference should not change, and the ActPos should not too as it's reading an absolute position value (raw data), so what could be changing the read value after a reset? (the motor is not moved).

[HomePos Behaviour Using SSI Absolute Encoder]

Hello, I'm working in a project and the Encoder I'm using is a SSI Absolute (25 Bits - 13 Bits Single Turn, 12 Bits Multiturn, Gray Code).

 

I'm currently getting a strange behaviour from the capture position. Everytime I do a reset with the motor in a position, the capture position changes to a different one, what is not expected from an absolute encoder.

 

Since the capture pos depends on the HomePos, I checked and it is what is changing everytime a reset is done. The HomePos is related to the last position before the reset and not to the reference zero as it should be expected while using an absolute encoder.

 

I would like to know what could be causing this behaviour and what parameter might be related to it.

 

Some Info of my project:

PowerBrick[0].Chan[2].SerialEncCmd = $1819;

Motor[4].pAbsPos=PowerBrick[0].Chan[3].SerialEncDataA.a;

Motor[4].AbsPosFormat=$72001907;

[Sys.Time Gathering and Gather File Limitations]

Changing gather.period to 2 worked. I guess that 10 kHz sampling frequency (servo frequency) was too fast for acquiring and wiriting data properly in this case.

 

Thank you all for the attention.

[Sys.Time Gathering and Gather File Limitations]

Is this number a large integer? If so it should be a number of servo counts.

 

You can multiply this by Sys.ServoPeriod/1000 to get time in seconds.

 

Yes, it worked, really thank you.

 

I still have the issue of the file limitation. Even if a change Gather.MaxLines to a high number (around 1000000), I'm still getting only 16000 lines that are just for the last 3.5 seconds of a 20 seconds motion program I'm running right now.

[Sys.Time Gathering and Gather File Limitations]

Hello, I'm having some trouble when trying to gather Sys.Time values into a file.

 

I'm running a motion program:

 

gather.enable = 0

 

Gather.addr[0]=Sys.Time.a

Gather.addr[1]=Motor[2].ActPos.a

Gather.addr[2]=Motor[4].ActPos.a

Gather.addr[3]=Motor[2].ActVel.a

Gather.addr[4]=Motor[4].ActVel.a

Gather.items=5

Gather.Period=1

 

gather.enable = 3; dwell 0

 

--motion code---

 

gather.enable = 0; dwell 0

 

enable plc GATHERPLC // sends system "gather -u /var/ftp/gather/data.txt"

 

But when I check the generated data file, the first column values does not match with the values I expected and see for Sys.Time on the Watch window. I tried to change Gather.Type[0] to 5, but I got weird numbers. The rest of the columns are ok with the variables as it was specified. I would like to have Sys.Time value in seconds.

 

Another problem I'm having is that the full motion program have duration of 51 seconds, and the gather file has only information for the last 12 seconds, it's missing data. Is it beacause of any file limitation size?