uno

Hello, I'm trying to find a good way for a motion program to stay "in sync with time" instead of extending motion steps, if the desired motion is too fast for the machine.... without feeding the trajectory as PVT. This means: Users sets a trajectory like: tm10.0 X1 Y1 tm10.0 X2 Y2 tm10.0 X3 Y3 tm10.0 X4 Y4 .... Now I have the problem that those steps are extended if they are outside of the limits. Especially when you try a "jump" you can watch the effect. What I (or better my boss an the customer ;) ) want is, that pmac tries to follow this path, BUT "skip" points, if the time is over. This is mostly for the times when simulation gives trajectories which are not correct limited, or which are intended to Essentially I looking for a good option to disable this "time extension". The PMAC should move as fast as the limits allow, but if the time for the next point comes i should no longer try to get to the "old point" but instead try to reach the next one. On point to make this easier: there is no need to fear that some "pole in the way" may be hit, if the PMAC does not follow the exact path. It is more critical that the PMAC tries to reach the points at the wanted time or skips them if he is not able to. On possible option as far as I see is: - make a "virtual fast motor" which has nearly no constraints - Feed the trajectory to this motor - make the real motor follow this motor with MasterCtrl = 1 and with MasterMaxAcc and MasterMaxSpeed set to the desired limits. That way the PMAC would make the virtual motor follow the wanted path, and the real motor would "follow it sluggish". We talk about a coordinate system with 2 axis. Now my questions: Is this the only way? Or are there better ways? What are the chances that this work "smooth"? Any other tips how to make this work good? What would really help would be a pointer in the right direction regarding "description of the virtual motor" and setup of the master following settings for the real motor. I have the virtual motors from some other thread here, which work for themself. I have also the following part working in general, but with the joystick for manual movement (and with MasterMaxAcc = 0 for no catchup) Right now I can only try with "all virtual motors" until next week. Next week I want to implement it on the real machine and hope that it works like simulated, but I'm sceptical. Hoping for some good tips, thanks, Georg

Well, this depends on the specific project. Sometimes I need some steps to shutdown a telescope. So I got used to make a shutdown PLC. In normal operation this gets called when the user sends some shutdown signal. While developing I call it myself, or, for convenience I thought "why not let it run automatically by pp_disable" . But if this is a problem I can work around it, now that I know. Thanks for this clarification :) Georg

Hello Eric, Since we sometimes need some specific procedure in shutting down everything I've started some time ago the following procedure, since as you noticed a "timed shutdown of several steps" is not possible with pp_disable.txt alone. I use a startup and a shutdown PLC. in pp_startup.txt I call the startup PLC with e.g. "enable plc 31" and in pp_disable.txt I call the shutdown PLC with "enable plc 30" Inside the shutdown PLC I disable step by step CPLCs, certain PLCs, after some time some other PLCs or UserAlgo.RtiCPLC = 0 and such stuff. Since it is recommended to use a startup PLC in pp_startup I expected that it would also be a good procedure to use a shutdown PLC in pp_disable, too :) Maybe this is not as intended? Greetings, Georg

Hello Steve, since we experience the same problems (though I've learned to live with them *sigh* ) I can tell you, that these problems most likely don't connect to those settings. If they were connected to these settings at the PCs end, it would mean, that other PCs could still connect to the PMAC, right? I've checked with many PCs connected to the same network as the PMAC while the PLCs were running. But I could not connect from any machine to the PMAC, while it was in this condition. So there are two possibilities: 1. Those mentioned settings are at the PC end, but break the ethernet at the PMAC (sounds unlikely, but would be an interesting solution, I'll try) 2. something else on the PMACs end breaks, and is not connected to the energy settings. @gmschoon: For a little help until there is a solution try the following: 1. extend in the project settings the projpp timeout time 2. set the Sys.BgSleepTime to a value greater than 1000 (default at 0 is 1000usec) at least while uploading a new project verison this helped a lot regarding "time needed" and "pmac broken, need to pull the plug" Greetings, Georg

Good Morning Eric, I've figured the problem out just before my vacation. It was most of the part my problem, but the backgrounds are interesting perhaps for some people: The problem was a "shutdown script" which I used, or better tried to use for uploading new versions of the project. Since we have a problem with the PMAC getting unresponsible a lot of times during upload, I had a script in pp_disable.txt which should disable some things which I thought are responsible for this. (ISR routine, some C Programs and such). No comes the interesting part: This script had a timer in it to shutdown in a specific order and wait between those steps. My idea was: pp_disable does what it does when I start the "build and download". Until everything is compiled (or at least until the new project is uploaded and started), my shutdown script will be finished and the PMAC is ready. But the actual reaction was: pp_disable gets called (somewhere after the files are already transfered to the pmac and some seconds before pp_startup gets called), does some stuff, and my timers are not finished yet. In the meantime the project starts with pp_startup. Now I think my shutdown PLC finishes or gets killed, everything gets stopped, including the startup PLC while it is in the middle of starting everything. This does not explain the reset of Sys.CdTimers or other stuff. But since I've removed the shutdown script and call it manually before upload, this strange behaviour is gone. So I do not fully understand the reset at startup, but it is connected to a plc called in pp_disable, when this script does some more complex things. Perhaps some procedure kills everything when some "old" plc is running. And I have experienced some race condition in this case where a running pp_disable part leads to a shutdown of the fresh started pp_startup stuff. something like: 1. start of pmac 2. make project ready 3. pp_disable -> wait a moment 4. kill everything old still running and stop everything 5. pp_startup And something leads to "5 starts before 4 finished" happens. Sounds weird, but I can not explain it better right now, since the analysis of this problem is some weeks ago. So anyway, I've fixed it, and it was for the main part a "self made problem". Greetings, Georg

Hello, I have a strange problem regarding the pp_startup.txt Since today I can not put PLC in there, which starts after powerup or $$$. When I update the PMAC it works with the automatic launch, even if I start the PLC in question by hand. But the autostart does not work at initial powerup or after a reset with $$$. To be exact, it works...but gets somehow killed. regardles of what is in the PLC (large PLCs, short one liners, commands, loops, system "....bla.out".) Everything gets started for a brief moment and then gets killed. I checked with counting up values. It counts up until some value and then the PLC gets killed. Initially there were some Sys.CdTimers in it. I recognized that they did also get killed somehow (set to a large value -> still 0. But counts down from the large value when started a bit later) Now this is a bit annoying since it did work until yesterday. Did someone else have such a problem and has a solution/cause ? Right now I'm thinking of making a init script in the linux part for startup as last resort. But other things short of that did not work. Greetings, Georg

Hello Eric, sorry for the late answer. I just did not notice that there were news in this topic. actually I'm not sure if I did not find this function until now or did discard it, because it sometimes returned the wrong time. There is a big problem with "initial startup" and some time functions on the PMAC. (sidenote: another problem is timespec and timeval. timespec should return nsec but actually returns usec like timeval...and I do not mean 1usec = 1000nsec ;) ) I have no clue how fast some ntpdate or chrony must set the linux clock at boot time, in order to get the correct time with for example "GetPmacTimeOfDay". I checked multiple times right now. 1. The times differ for nearly a year or so, if it was not fast enough synced on boot. That means always after "cold boot" I have not the correct time with GetPmacTimeOfDay. Every "build and download" of changes did not change this beheaviour. In this state only a $$$ worked after the linux clock was set to get the correct time. 2. What makes it worse: it drifts away. I did call both at the same method time in rticplc.c. Afther that i substracted the times and got a increasing difference. Right now I had -0.72, which means gettimeofday is about 0.7 seconds ahead of GetPmacTimeOfDay. Long story short: After these tests I can say that GetPmacTimeOfDay ist not usable for our needs here right now. Do you have an solution for this? I could of course get time with gettimeofday. Compare it than to GetPmacTimeOfDay. And when they are not in sync I could issue $$$ from a PLC to restart the firmware. But this does not look like the "right way".

Hello again, is it possible to read the program contents also in C? If not, what would be the best way to get it? We send trajectories in a simple protocol to the PMAC. its always a tupel of 3: [movetime, axis1 endposition, axis2 endposition] somebody wanted the possibility to readout a trajectory (although they have to send it first, so they should know what they have sent...) So I'm facing either "parse the output of 'list prog x'" or perhaps there exists and easier way. I would rather not parse strings ;) Greetings, Georg

Hello Eric, Yes, I use it at different locations. And yes, in this project I can avoid it and call it at a central place. I tried to reduce these calls allready before your answer. So perhaps this is the reason why the "long time freezes" don't appear that much anymore. If you could reproduce these problems, then I'm hoping that these also relate to my problem. After all these "freezes after some longer time" were not here in the beginning. They appeared somewhere while wrinting the rest of the programs, so chances are that they got in when I implemented the timestamping. The whole observation of these freezes calls for something like "not enough pause" and "timing issue". I will try to reduce the calls to that function more. On a different project I make timestamping in combination with ServoCount, clockspeed and some defined "time to servocount mapping"...This way I could reduce it further to calling it about once every seconds and make the rest with Sys.ServoCount. Thanks for your Help, Georg

Edit: found one problem, for the critical "quick freeze": I added one GoBack on the wrong position and wrong value... But the freezes after a while might still be there (in the range 1+hour, but not critical for now). I is too much offtopic now here, since gettimeofday() is most likely not the problem. But is there a possibilty to PM one of you guys to discuss some more details which I'm using and perhaps not in a way it should be used, which might cause the sudden problems? original text ======= Hello, I'm using inside the "Linux background programs" and inside RTI CPLC the "gettimeofday()" from 'time.h'. this works so far and worked well until last week. My CPU load did not show any problematic signs... the Symptomes are like: PMAC Linux unresponsive, so no SSH or so. But (some) PLCs are working. I have one PLC which only toggles an LED on the ACC65E, which is still happily toogling away while the SSH Part freezes. (not always, but I did not systematically watch all things...this I start today ;) ) Regarding the freeze problem and the time: I tried to reproduce it on another PMAC, but this one has no ACC65E and no ACC74EX with canbus. I could not get it to freeze there. So Right now I'm quite sure that none of my background Programs (using the manually scheduling library and TCP/UDP sockets) or the gettimeofday() inside RTICPLC. It could perhaps be some problem in combination with the CanBus or other stuff ,which is only available here at this specific PMAC. At the moment I'm trying to put an old version of the project on the PMAC, which did not freeze (at least not after 20 minutes). Perhaps I find the problem. Well, long story short: right now there is a chance that the freezing here has nothing to do with the gettimeofday(). But I was hoping Eric did find some "good to describe problem" which perhaps lead to a solution at my place, too. Greetings, Georg

Hello Eric, right now I'm observing some freeze problems, too. Ath the moment I'm far away from the PMAC in question, and have only another with some different cards in it (no ACC65E, ACC72EX, only one ACC24E3,2 channel instead of 3x4 Channels). So it is difficult to reproduce...still I try to find the reason. Since I'm experiencing the same problems and using these methods, too: Dind you find any reason for this problem? Or do you have at least found a solution for this problem? My usecase right now: PMAC UMAC, 465 CPU dual core I'm calling 'gettimeofday' from RTI Cplc, background C programs and I'm also using the custom threading library. Also in the linux part there is a chrony daemon running which updates the time. Since a few days I have increasing problems with freeze/lockup/software watchdog trip or something else. Even with a state of the project which was once quite stable. So if You have found the reason why the 'gettimeofday' is locking up the PMAC, this might be helpful debugging my problems. Right now I'm just putting some of the programs on another PMAC I have available right here, but the Projects are too different so it is difficult to reproduce these errors. Perhaps you have some idea, Georg

Hello Eric, We sell the ACC-24E3 with two sinusoidal interpolator options; standard and auto-correcting. The velocity and acceleration data require the auto-correcting option. thanks for the clarification. I think we have the "non auto correcting version than. I'll check the order later, but this should be the reason than. In theory, this would be done either with "EncTable[2].pEnc=EncTable[1].DeltaPos.a" or "EncTable[2].pEnc=Motor[1].FltrVel.a". However, either of these will throw a "error #70: Struct Write Data Error". If you wanted to force this method to work, you could repeat Motor[1].FltrVel into Sys.Udata in a custom servo algorithm so that on the next pass through the ECT the value is available. Set Enctable[n].pEnc=Sys.Udata.a to read the copied FltrVel. That I tried, and yes, with the error message you mentioned :) Thanks for the "forced method". Perhaps not with this problem, but at other places I will try this...eighter for good reasons or just to have fun. If you do the calculations in C they should be about the same as the ECT, where script would be a little slower. Ok, than I use the "good old C way", if this is the same speed. Thanks for all the insights into the ECT. Now a lot is clearer to me, and my mind can rest regarding the "ECT should be faster or more beatiful" topic :) Now, back to my telescope, Thank You for now and see you later with new problems, Georg

Hello again, Eric ;) thanks for the answer. The version with DeltaPos I tried yesterday, since this appeared to me as the "normal mathematical way". But now two questions arrise: 1. It should be possible, to feed DeltaPos (or FltrVel) into another ECT, to get then DeltaPos for this value, and have acceleration, right? But how would this be done? Just point another EncTable to this DeltaPos or FltrVel? (type = 1? ) 2. My main reason for all this trial and error over the years with "outsourcing to the ECT" was "speed" or "less calculation time" and of course "keep it simple". My understanding is, that the ECT is somehow good optimized for such calculations. So if I write my own calculations, I could mostly not be faster, compared to "if I did it the correct way inside the ECT". It seems to me that by moving such repeating calculations to the ECT, I save time, keep problems with other code parts away and make sure I always have the values I want calculated and ready when the rest of the programs need it. Is this correct? Or is the effort to move these calculations to the ECT in the end not making any difference compared to PLC/plain C calculations? Greetings, Georg And short regarding the interpolator: Yes, the incremental encoder use an interpolator, but I'm not sure about the auto correction. Its an Heidenhain EXE or IBV, not sure right now which one I used for my short experiments. But from my point of view I just use the "$$$***" defaults for AquadB encoder on the ACC24E3 channel and it works. So the PMAC should only see the pulses. Could this be the problem? Our electrician is on vacation right now, so if it is worth digging further there, perhaps I ask you later about this. This telescope is about 30 years old. Some parts are original, some have been replaced, so I'm not sure about all details right now.

Hello, Up until now I've rarelly used or needed the features of the ECT. Mostly I had some absolute and some A quad B Encoders, and got all I needed without much changes there. But there were always some things that I calculated myself, but should in general be possible with correct setup of the ECT. Perhaps there is also a fundamental problem I'm not seeing. The ECT was always a big mystery. I think a lot of things can be done with it, but every time I try something, I don't get it to work and write my own code for the specific problem. Now at my current project I need some estimate of the current acceleration and jerk of a telescope. So this means 2nd and 3rd derivative of position. The customer wants these for logging purposes, and knows that these values are not too exact. But anyhow, I need to send them with every position package, and I'm looking for a way to calculate this using the ECT. In TurboPMAC there is more about differentiation in the ECT (although not enough for me to try and use it back than when we used TurboPMAC), but with PowerPMAC I can only find everywhere "you can differentiate with the ECT". But not "How"? I've just looked again at the training slides, but even there it stops at the end with Triggered timebase. (In Turbo PMAC there was also a "non triggered timebase", but this seems gone?) So, my question is: Is there any more documentation/examples for the ECT? I'm right now thinking that I have overlooked something...Or think too complicated. But I would also be grateful for an example, how to get velocity, acceleration and jerk by using the ECT to put it into some variable to send it somewhere. So how to configure the ECT 3-5 to process the position of the Motor in e.g. EncTable[2] to get velocity, acceleration and jerk of this motor? I have no Trigger attached to IC Channels to trigger from external. Which is not needed for this problem I think. (ok, I could wire something from an ACC65 to the ACC24E3 Inputs, but there must be another simple way for my problem) Greetings, the guy who somehow does not understand how to use the ECT ;) A question related to this, but not so critical right now: I've also found in the ACC24E3 manual a way to ask for additional data using the Gate3.AdcEncStrobe. (Direct Velocity Value, around page 59) But eighter I'm missing some critical piece, or these values are not retrievable with the system here) Using the example on this page I never get any change of the result.

Hello Eric, sorry for the late reply, I had a bit of vacation :) I'm using a english windows 10, but have the region format switch to "Germany" to have the date and some other number related stuff right. But Region Settings in windows are a big problem, and I think its getting worse with every version. For example: In Acrobat Reader I can switch the Paper format from letter to Din A4, but after I close the program, this setting is gone. Somehow Acrobat is assuming some settings derived from some language settings... The same goes for Libre Office, but I think there is at least some setting no to set the decimal separator on the number pad. To come to your question again: Usually I have windows configured windows in English (US), and the "Format" under "Region" in the control panel is set to Germany. The Language for non unicode programs is set to English (US) The main problem with this constellation in many programs is the different decimal separator: English its a dot, German its a comma. Some of these settings are only really applied after a reboot or re-login, I think. Anyway, now it works. :)