hannsx
-
Posts
102 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Downloads
Posts posted by hannsx
-
-
Ok - after having removed the code resetting some flags including flags accessed by the ISR, the pausing only occurs at the end of the move when I export the data, which indicates that it are the BgCplc - programs causing the issues.
-
I have an Update on my Issue. The ISR does not crash anymore if I do not reset certain UserSharedMemory registers at the end of the iterated
motion. I use UserAlgo.BgCplc[1] to reset the registers since I can not run through the register - adresses in while loop in plc programs. Is there maybe a concflict between the UserAlgo.BgCplc[1] and the ISR ? It seems odd to me that resetting these registers in the CPLC does have this effect. However the irregular pauses inbetween moves are still there. Maybe this too is caused by my two BgCplc - programs.
-
Hi, I have the problem that while my program is running the ISR freezes on random occasions. My Program consists of a motion from a) to b) getting repeated as many times as I like.
While the motor is jogging to position a) I have the CaptCompISR logging the position. The purpose of it is to check if the Motor was on the position corresponding to the number of the trigger that launches the ISR and then to induce a position correction if it isn't.
The position correction is calculated and induced by the custom phase algorithm assigned to Motor[0] while the Motion is carried out by Motor[1].
At first I had the code for storing the captured positon inside the ISR but moved it to the phasealgorithm in order to exclude it as a cause for the error and now moved back again.
I also made sure I had nothing else but "int"-variables in the ISR. If I iterate the motion loop 500 times the ISR freezes at least 2 to 3 times. I can get it to work again by reading the "Gate3[0].Chan[0].HomeCapt" register from the terminal. I guess why this is happening is that the "Gate3[0].Chan[0].Equ" bit turns high. Though the ISR does not always freeze when it turns high, every time it freezes the bit is high. So I added some lines of code out of the Equ Compare example featured in the User's Manual which forces the Equ-State to zero. This had no effect on the freezing of the ISR. The only thing that makes my ISR restart automatically is to read the "Gate3[0].Chan[0].HomeCapt"-Register from a plc. This too is not perfect because my Motion seems to sometimes stop for 1/10 up to 5/10 of a second at the end of the move or just after having reached the starting position again, sometimes several times a row. Then again it runs smooth without pausing. I tried deactivating the Equ State inside the ISR and inside the plc but without effect. I had a plc runnning the code the guy posted above for making sure the Equ-state does not turn high, but that too did not have an effect. Does anyone have some further info on that? This is the code I have in my ISR:
void CaptCompISR(void)
{
int MyFirstGate3Adr = pshm->OffsetGate3[0] ;
volatile int *MyFirstGate3IntCtrl = NULL ; // InCtrl direct register pointer declaration
MyFirstGate3IntCtrl = ( unsigned int * ) piom + ( ( MyFirstGate3Adr + 0x224 ) >> 2 ) ; // IntCtrl register adress calculation 4bytes Per Word
// Deactivate ISR
*MyFirstGate3IntCtrl = !( *MyFirstGate3IntCtrl | 0xffff00ff ) ; // ( NOR - Operation ) 24 Bit - Bit Nr.16 has to be set to zero
*MyFirstGate3IntCtrl = *MyFirstGate3IntCtrl | 0x00000001 ; // Clear interrupt source
int *CaptCounter = NULL ; // Logs number of triggers
CaptCounter = (int *)pushm + 60200 ;
volatile int *MyFirstGate3HomeCapt = NULL ; // HomeCapt direct register pointer declaration
MyFirstGate3HomeCapt = ( unsigned int * ) piom + ( ( MyFirstGate3Adr + 0x74 ) >> 2 ) ; // HomeCapt register adress calculation
int *CaptPosStore = NULL ; // Storage pointer
CaptPosStore = (int *)pushm + *CaptCounter + 65000 ;
// Determine Shared Memory-Pointer Adresses
int *StartScan_C = NULL ; // Pointer zum setzen des Flags für den Start der Scan-Fahrt
StartScan_C = ( int * ) pushm + 60100 ;
int *PulseInt_C = NULL ; // Switch for executing correction in PhaseRoutine
PulseInt_C = ( int * ) pushm + 60101 ;
*PulseInt_C = 1 ;
int *IsrCheck_C = NULL ;
IsrCheck_C = ( int * ) pushm + 60221 ;
(*CaptCounter)++ ; // Increment counter, starts at 0
(*IsrCheck_C)++ ; // Checking variable
if ( *CaptCounter != 0 ) *StartScan_C = 1 ; // Prompt plc 7 to start motion
}
-
Ok - that's what I searched for. Thank you for the information and your advice.
-
Thank you for the help - that surely is a nice approach I wouldn't have thought of. Do you know if loops written in a motion program or a plc are iterated multiple times in one rti?
-
Hi,
I am using a PowerBrickLV in combination with a linear motor. The encoder resolution after 4xinterpolation is 50nm.
I move my Motor to the starting position for the move. Then I start the motion program:
-------------------------------------------------------------------------
open prog 2
rapid;
abs ;
Motor[1].JogTa = -0.01 :
Motor[1].JogTs = -0.01 ;
Motor[1].JogSpeed = ScanVelocityMs ;
while( StartScan == 0 ){ } ;
Y( ScanDestination ) ;
close
-------------------------------------------------------------------------
I thought it may be the faster way to get the move started after the StartScan bit is changed to 1, compared to querying the value in a PLC and starting the program from there. The reason why I think so ist that when I look at the program interrupts scheme, the motion program calculations start before the PLC - programs are run. Another reason is that, if the while-loop is iterated multiple times in the time slot allocated for the motion program calculations, the motion would start immediately if the StartScan value changed in the process of iterating. In a PLC on the other hand the StartScan would only prompt the starting of motion program 2 and the motion would then start on the following rti - interrupt.
Am I making the right assumptions here? If you know a faster way to start the motion please tell.
And I wonder if the while-loop is iterated multiple times in any real-time-interrupt, either in a motion program or a PLC.
Best regards,
hannsx
-
I got the advice from the support to realize my application in either the servo or phase interrupt, as there are no benefits from having position corrections faster than these. In these Interrupts there are no Limitations to the data formats,
best regards,
hannsx
-
Hi,
in the User Manual it says that I can not use float variables or math in the ISR. So is it not even possible to declare a float pointer and to do a typecast of an integer value to write it to that pointer?
I would like to use the speed of the ISR to inject a position offset and would therefore need to write to the floating point register Motor[x].CompPos.
Ii know that injecting a position offset is possible by using a 0D-Compensation Table, but is there a way to accomplish what I have in my mind?
I am using a Linear Motor on a PowerbrickLV,
best regards,
hannsx
-
Hi Chris, thanks for your reply - I have solved the problem as mentioned in my first post. I realize that it would have been better to emphasize in the header that the problem is solved - I'll try to change that
-
Update - When I kill the Stepper on Channel two it still has a holding force. Strangely I can not measure any Voltage on the either phases. I can only measure 0.12mV between phase 1Out and phase 2In. However I can not measure any current apart from negligible 0.3uA.
When I plut the Stepper in, it gets locked to a phase again. I also thought of maybe having written a value to a IO register when I experimented with the Analog I/O Output but that should have been set back to the default on any PowerOnReset and when I checked the registers I coudln't find any errors
-
Update - The Stepper in a separate Project-File runs on Gate3[0].Chan[2] but not on Gate3[0].Chan[1].
Just like I wrote in my inital Post. One more strange fact is that the Motor does still holds its position after I have killed
it, so it is still powered. I can provide the Files if someone wants to look into them.
-
Update - I was able to get a Brushless to run on that channel from another Project-file. I don't know what to make of it. I'll search for errors related to PowerBrick[0].Chan[1] in the Project having the trouble. I'll try to get a single stepper to run in another Project-file now as well. Any hints to typical mistakes are welcome
-
Yes - that is set to 1.
BrickLV.Chan[1].TwoPhaseMode = 1 ; //For Motor[2]
I wrote Channel Nr. 2, maybe a little confusing.
-
System: PowerBrickLV, Axes 1-4 5/15A, Axes 5-8 1/3A
While setting up my PMAC for the control of drives on our machine I could not get anything on Channel Nr.2 to run. I wanted to run a 2-Phase stepper motor from oriental motors, with 0.9°/full step. It ran as desired on Channel nr. 4. So to eliminate possible programming errors I just copied the working code to Channel Nr. 2 replacing the variables accordingly. But the Motor just turns hot after a while.
Is there a mistake I could have made?
How do I know if the channel is broken?
-
I think so now too
-
Ok - I see. So it is only the current sensor.
I took the 80V from the maximum allowable Bus Supply Voltage.
I wish to fully understand what I am working with to be able to fit all the pieces together from the technical manuals etc.
I want to understand this in particual because I sometimes obtain current loop gains that don't work. In cases like that it would be helpful to have a manual estimate as to which values are sensible.
Is ODT short for Omron Delta Tau?
-
that sounds good, do you refer to the resources available on youtube and the file depot?
-
I work with a PowerBrickLV with a maximum ADC current of 33.85A and yes, I close the current loop in the PowerBrickLV. The Maximum Voltage is 80V - Is that equal to the Maximum the ADC can read? If I got it right the Resolution of the ADC is 16 bits.
Quote from Manual:
"I_sat Maximum (saturated) current reading from phase-current A/D converter (Amps).
This is a DC value, not an RMS AC value.
This value can be derived from the current-sensor gain K_c (volts/amp) and the maximum
voltage in volts that the A/D-converter can read V_cmax: I_sat= V_cmax/K_c"
Is it as simple as this:
K_c = 80V / 33.85A ?
-
I read this white paper which touched upon the issue of commutation resolution
http://www.deltatau.com/Common/support/whitepapers/High%20Speed%20Machining.pdf
Maybe this is what you refered to
-
Hi, thanks for the answers. I think I confused the function of the commutation and the function of the servo algorithm - but now it seems clear to me.
-
Hi, I am sorry I didn't respond earlier. I assumed I would see some kind of notification and I didn't explore my user account until now. My prefered way of getting motors konfigurated is now to start with the PowerBrickLV Hardware Refernce Manual, get the Info on the direction of commutation from the setup program and then tuning the motor. Additionally I often look into the User's Manual for further Information.
-
Hi,
I wanted to calculate the current loop gains for my stepper empirically according to the instructions given in the Power PMAC User's Manual from page 270 onwards.
Therefore I need I_sat. And to get I_sat I need to know K_c, the current sensor gain.
So my question is: - How do I get K_c or how can I derive it from measurements,
best regards,
hannsx
-
Hi,
I tried to find a direct answer on how the commutation is fine tuned for values between the 2048 resolution.
Are these values of the table entries just interpolated linearly to give a precise approximation beforehand or is it left to the current loop algorithm to do the fine tuning based on the position error correction afterwards,
best regards,
hannsx
-
Hi, I want to share my problems and solution for other people to benefit of it.
The File ist not available on the File depot, so you have to specifically
ask the support for the newest File. In my case I got the Files from my
supervisor and that did not work.
Problem: I was not able to connect to the MotionCore.VBox Machine with my PMac IDE.
Solution: Use the newest MotionCore.Zip file.
The File ist not available on the File depot, so you have to specifically
ask the support for the newest File. In my case I got the Files from my
supervisor to start with and that did not work.
RESOLVED - CaptCompISR freeze
in Power PMAC
Posted
Hi, this issue has been raised in this thread some years ago:
http://forums.deltatau.com/showthread.php?tid=1233
I applied the advises given there but could not improve the situation by that. However I discovered that the ISR does not crash anymore if I do read the Gate3[0].Chan[0].HomeCapt register while scanning for the first interrupt to start the motion. But because this is only a workaround I describe the problem I had.
I had the problem that while my program was running the ISR froze on random occasions. My Program consists of a motion from a) to b) getting repeated as many times as I like.
While the motor is jogging to position a) I have the CaptCompISR logging the position. The purpose of it is to check if the Motor was on the position corresponding to the number of the trigger that launches the ISR and then to induce a position correction if it isn't.
The position correction is calculated and induced by the custom phase algorithm assigned to Motor[0] while the Motion is carried out by Motor[1].
At first I had the code for storing the captured positon inside the ISR but moved it to the phasealgorithm in order to exclude it as a cause for the error and then moved back again.
I also made sure I had nothing else but "int"-variables in the ISR. If I iterated the motion loop 500 times the ISR froze at least 2 to 3 times. I could get it to work again by reading the "Gate3[0].Chan[0].HomeCapt" register from the terminal. I monitored the "Gate3[0].IntCtrl"-word and saw the "Gate3[0].Chan[0].Equ"-bit for turn high and low very often as my program was running. My first guess was that this was the cause for the freezing. Though the ISR did not always freeze when it turned high, every time it froze the bit was high. So I added some lines of code out of the Equ Compare example featured in the User's Manual which forces the Equ-State to zero. This had no effect on the freezing of the ISR. The only thing that made my ISR restart automatically was to read the "Gate3[0].Chan[0].HomeCapt"-Register from a plc. This too was not perfect because my Motion seemed to sometimes stop for 1/10 up to 5/10 of a second at the end of the move or just after having reached the starting position again, sometimes several times a row. Then again it ran smooth without pausing for while. I tried deactivating the Equ State inside the ISR and inside the plc but that too without effect. I had a plc runnning a code the guy posted in the old thread for making sure the Equ-state does not turn high, but that too did not have an effect.
I would be grateful for any further insights into this and would also like to know if there is a way to reliably stop the "Gate3[0].Chan[0].Equ"-bit to turn high.
This is the code I have in my ISR:
void CaptCompISR(void)
{
int MyFirstGate3Adr = pshm->OffsetGate3[0] ;
volatile int *MyFirstGate3IntCtrl = NULL ; // InCtrl direct register pointer declaration
MyFirstGate3IntCtrl = ( unsigned int * ) piom + ( ( MyFirstGate3Adr + 0x224 ) >> 2 ) ; // IntCtrl register adress calculation 4bytes Per Word
// Deactivate ISR
*MyFirstGate3IntCtrl = !( *MyFirstGate3IntCtrl | 0xffff00ff ) ; // ( NOR - Operation ) 24 Bit - Bit Nr.16 has to be set to zero
*MyFirstGate3IntCtrl = *MyFirstGate3IntCtrl | 0x00000001 ; // Clear interrupt source
int *CaptCounter = NULL ; // Logs number of triggers
CaptCounter = (int *)pushm + 60200 ;
volatile int *MyFirstGate3HomeCapt = NULL ; // HomeCapt direct register pointer declaration
MyFirstGate3HomeCapt = ( unsigned int * ) piom + ( ( MyFirstGate3Adr + 0x74 ) >> 2 ) ; // HomeCapt register adress calculation
int *CaptPosStore = NULL ; // Storage pointer
CaptPosStore = (int *)pushm + *CaptCounter + 65000 ;
// Determine Shared Memory-Pointer Adresses
int *StartScan_C = NULL ; // Pointer zum setzen des Flags für den Start der Scan-Fahrt
StartScan_C = ( int * ) pushm + 60100 ;
int *PulseInt_C = NULL ; // Switch for executing correction in PhaseRoutine
PulseInt_C = ( int * ) pushm + 60101 ;
*PulseInt_C = 1 ;
int *IsrCheck_C = NULL ;
IsrCheck_C = ( int * ) pushm + 60221 ;
(*CaptCounter)++ ; // Increment counter, starts at 0
(*IsrCheck_C)++ ; // Checking variable
if ( *CaptCounter != 0 ) *StartScan_C = 1 ; // Prompt plc 7 to start motion
}