Jump to content
OMRON Forums

jsinoir

Members
  • Posts

    22
  • Joined

  • Last visited

Everything posted by jsinoir

  1. Hi , OK thank you, I'll try the new IDE, but I understand it will probably make the false error dissapear without solving our jog issue. cheers, Jeremy
  2. Hello, I am working with Bernard on that issue. I notice something with the new IDE we just installed : during normal operations of the machine we very often have the CoordExecStatus[x] alarm being raised, I don't find any reference of it in the User Manual and in the SRM. would anyone know what causes these alarms ? And if they can be linked to the problem described by Bernard ? Have a good day, Jeremy
  3. Hello, I have a problem trying to install the Power PMAC IDE on a windows 7 machine : as soon as the Isolated shell starts It fails rising an error : "Microsoft visual Studio 2015 has stopped working" error code : CLR20r3 I tried to install the Isolated shell with other versions (2011, 2013, 2015) , it does the same all the time. has anyone already seen that ? Have a googd day, Jeremy
  4. Hello, Thank you very much for your clarification Curt, we will replace the coder by a pulse generator to try to validate that. Your comment about DSPGATE3 is also very interesting. That would be a great alternative, an other alternative we considered would be to use a Serial encoder , but both these solution are unfortunately impossible for us because we are restricted to our CPCI rack format, which does not accept yet the DSPGATE3 cards ...
  5. Hello, thank you for your answer, we thought of that, but we discarded that explanation given that the frequency of our A and B lines is 4 times lower than the frequency of the coder steps. That means that the analogic sinal we try to convert with our digital circuitry is not 20 MHz but 5MHz which is way below Nyquist criteria. Am I wrong to assume that ? Thank you very much for your help. have a good day, cheers, Jeremy Sinoir
  6. Hello, We have a problem with one of our setup, we try to use a coder with a 5 nm resolution and we want to go at 100 mm/s the channel EncCtrl is configured in *4 quadrature CW The motor DAC is on IC 2 whereas the coder is on IC 4. the HardwareClockCtrl of the IC 4 is set to 2256 to be able to benefit from the 39MHz SCLK. (the HardwareClockCtrl of the IC 2 is also set to 2256 although I suspect this is not necessary) in principle 100mm/s = 100nm/us =20 cnts/ us = 20MHz < 39 MHz so we should be able to reach these speeds. but what we see in practice is that the CountError flag is raised somewhere around 65 mm/s which is equivalent to an input frequency of 13 MHz and we indeed see that the repetability of our movments suffers (steps are indeed lost) when the speed goes higher than 60 mm /s Am I missing a parameter ? our coder is capable to generate reliable quadrature signals at 250 mm/s . the signals coming out of it look OK, not noisy, apparently free of any forbidden transitions . Have a good day, cheers, Jeremy Sinoir
  7. for those who might find interest in that discussion, the jitter problem has also been fixed . the content of the discussion that lead me to the solution can be found here : http://forums.deltatau.com/showthread.php?tid=2795
  8. Hello, Curt, thank you for helping me once again, I read about the level triggering in the doc, that is why in my PLC I protect the call to HomeCapt with a check : if ( Gate1[14].Chan[3].ABC <4 ) that is to ensure the C channel of the coder is down while I read the flag (it triggers on index C high) I also was carefull about the watches windows. But yesterday evening I found my problem. indeed I plotted the state of the arming flag (posCapt) and the C channel at the same time, and although my C channel was perfectly good , the arming signal was erratic. More interesting, the capture signal stopped to be erratic when I cut the power of the main motor. My biggest mistake was to only rely on the PMAC scope to look at the C channel which was always looking super good despite that the real signal was less clean and messy just enough to mess up with the capture but not the content of the Gate1[14].Chan[3].ABC signal ! It was causing all my problems, also the ones I had with the trigerred time base system. now this fix has removed what we called the "jitter" which is now almost equal to the following error, and what we called the "offsets" has been fixed by using the calibration movement (1 triggered move that I do just to measure the offset ) and then I apply this offset to the following moves of the program (the time base is re-frozen briefly) This now looks super good. Thank you very very much for your help. have a good day. Cheers, Jeremy
  9. I used to do that, that is why my phase clock runs at 144 KHz (there used to be a phase algorithm) but as it was causing me a lot of confusion about what was updated and what was only depending on the last servo cycle, I stopped bothering to use that , and went back to the plc0 (thinking it was fine as 9KHz gives me 9 cycles to do the reading , (4 if you consider that I only allow mysel to rearm during a low-state of the C channel))
  10. I use a Power PMAC CPU in CPCI format with ACC24C2A 4 axis cards, it talks to an external driver in +-10V which drives a linear motor (brushless) from faulhaber my encoder is a mercury II encoder, optical encoder with 5 nm resolution my code is described in the plc0. because I thought that it was really running at rti frequency (as a compiled rticplc) is that wrong ? in my setup I have set the phase clock at around 144 kHz, servoclock at about 9Khz (110us) and rti same as servo here is the plc 0 open plc 0 p2017 = Gate1[14].Chan[3].PosCapt; if ( Gate1[14].Chan[3].ABC <4 ) { if (p2017 ==2 && p2019==1) { p2019 = 0; p2010 = Gate1[14].Chan[3].HomeCapt; difference_to_previous = p2010 - p2011 p2011 = p2010 } } else { p2019 = 1; } close
  11. YES ! once again your answer has been super usefull for my tests, now I do a sample movement in triggered time base, measure my delay during that sample , come back to 0 , rearm the trigger and prepare a move wich contain an offset proposritonal to what I measured just before , and bingo ! the following moves are perfectly centered ! Thank you very much !
  12. Hello, I just did a measurment that I don't understand. I have a set of 2 signals one is a 1KHz pulse signal , the other one is a 256KHz quadrature signal perfectly synchronized with the 1KHz I plugged the 256K signal on a motor A B channel and the 1K on the C channel Then I setup the trigger for this motor to react on a up level of the C channel, I then built a plc to read and rearm automatically the trigger and give me the difference in position between 2 triggers. I get a perfect 256 all the time. so the triggering plc seems OK I now plug the 1K signal to the C channel of an other motor, a real motor. and I did the exact same. I jog my axis at 5um/ms and I read the difference of position between 2 triggers.. what I obtain is a really noisy signal centered on 5um but with a big jitter (+ or - 2 um) so I get distances between 2 pulses varying from 3 to 7 um what bothers me is that it does not relate to my following error, indeed, when I plot the following error at the same time, it only varies of + or - 300 nm . so my expectation was that I could have a maximum of twice the following error in my difference , so never more than 600 nm... The only explanation I can come up with is that pmac the following error showed by PMAC is good because it is sampled at the same rate as the reaction time of the servo loop. but what happens between 2 servo cycles can be much more dramatic than the following error ! but this is scary, could it mean that every time I manage to regulate a motor down to 200 nm of following error, I can actually have 2 um without knowing it ? I am doing this because I am studying a setup to use an external clock (so fundamentally asynchronous) to command a position on a motor. (the motor has to be at a designated position at every tic of the clock without making stops (as if the move was linear))
  13. OK, I just did that test, and I have the exact same profile, except for the high freq oscillations that used to occur during the acceleration times. but the offsets are still there, exactly symmetrics around 0 and have the same value . the jitter is also still here but that is not a surprise. I also plotted Motor[].desPos , it is perfectly triangular. so to me this definitively looks like a t0 problem either in the measurment method or in the actual trigger. I trigger with a plc0 running at 110 us, the program prepares the variables and freezes the time base . then the plc 0 waits for a global variable called armTimeBase to be manually put to 1. when armTimeBase is 1 it checks that the Gate1[4].Chan[3].ABC is < 4 (meaning that index is down) and as soon as it sees this, it puts EncTable[5].index1 at 2, so in principle the next rising edge of the clock should unfreeze it ...
  14. Hello, Thank you very much for your answers, I answer to number 2 , I will try number 1 during this morning : I saw that in the power PMAC manual, but I thought it was not a problem for my use-case. I don't see what should be changed in my calculations to take that into account, I only thought that ; yes, the first deltaPos will be smaller , but that is good , that is to ensure that my t0 is properly defined on the trigger and not on the next servo cycle after the trigger, and then I don't see how it could impact the fact that if I asked pvt(200) A(0)(5000) the moment when A crosses again position 0 should be almost perfectly aligned with the 200 th tic of my clock (and the 128*200th tic of my fast clock) , and even more perfectly if I consider the desiredPos instead of ActPos (with an error only due to my measurment plc but this one is much faster than a servocycle (144KHz)). I am certainly wrong in some way, but I don't see what I am missing. thanks again, cheers, Jeremy
  15. Thank you if you had the patience to read me up to here, I don't know if that behavior of the desPos is coherent, if I am at the limit of what the time-base system can offer, or if I am just missing an obvious point, but I don't manage to have this solution working for now. I can provide all my programs, plcs and configuration files if needed. thank you very much, have all a very good day, cheers, Jeremy PS : Sorry I used replies as paragraphs separators for clarity, if that is not OK with the forums guidelines, do not hesitate to tell me , I will put it back together
  16. Noticable facts : 1. the offset from 0 as shown in the first graph is always the same when I re-run my program , except for the first time when it is usually much worse (I did not dig into that, thinking it was due to a P0 capture problem in my code) 2. I used to have a PVT point at each passing point distant of step_size form the previous, now I switched to a single pvt point at the beginning of the line and one at the end (and trust PMAC's trajectory builder) . when I add so many pvt points, the distance to 0 of every line was growing of a constant value over time ! my steps were getting more and more far from 0 at every new line, this was repeatable if I re-run the program. now with less points or in linear , the distance to 0 is the same in both direcion and at every iteration (only the sign changes depending on the direction) 3. I used to make my unfreeze on a negative limit switch , now I switched to a C line of the simulated coder , this had the effect to make my distance to 0 bigger (was 500 nm before, is 1.2 um now)
  17. Here are all the things I did to try to fix the problem : 1. thinking it was a plc jitter problem, I put my measurment code in the phase routine of a spare motor which runs at 144Khz. with that speed I was expecting during the constant speed a measurment jitter that would have the value : commanded_motor_speed * measure_period = 5 um/ms * 7 us = 5*0.007 = 35 nm but the jitter I observe is 500 nm and the distance between the center of this jitter and the actual 0 as shown on the first graphic is also about 500 nm which makes for me spikes of up to 1 um in the desired position which is already taking all my acceptable error , so when I add my following error .. I am dommed (my motor usually performs at this speed with a following error below 400 nm) 2. I was thinking it could be the capture of my P0, but as the motor is still when starting and I take the P0= desPos, I have something perfect here. 3. TimeBaseSlew too low ? I put it to 30 (It was already at 1 as specified in the doc) and then 30000, not better 4. acceleration and decelration of the motor not Ok ? we are far below what the motor can take and I put 0 in invAmax, invDmax and invJmax 5. problem during the acceleration ad decceleration phases ? : I put a rearm request in the middle of every u-turn with a dwell 0 and a re-arming from a plc -> no change at all. 6. time base not liking the PVT moves ? : I re-wrote the same program with linear motions : same results
  18. I thought this could be caused by my motor regulation, so I deceided that instead of plotting (motor.ActPos- P0)% step_size I would plot (motor.DesPos- P0)% step_size And I had a very similar result ! my following error was just adding a little noise over somethhing already not OK if I zoom in on a constant speed motion the desPos modulo looks like this : ..../...../...../..../..../ .../|..../|.../|.../|.../| ../.|.../.|../.|../.|../.| ./..|../..|./..|./..|./..| /...|./...|/...|/...|/...|
  19. Hello, I am currently trying to synchronize an axis on an external clock. The purpose is : starting at a position P0, we want to be at P0 + n * step_size at every tic of the external clock (after an acceleration phase of course, no step-by step motion, but a continuous scan) , the axis should also be able to deccelerate, and re-accelerate in the other direction to redo the scan in the other direction without loosing its synchronicity. It is possible to receive an additional clock whose frequency is an exact multiple of the base clock. In my main use-cases, the base clock is 1KHz and the fast clock is a 128KHz. Triggered time base seems to be the appropriate tool for that , so I input my 2 clocks on a spare motor coder lines (fast clock on A/B and base clock on C (as you guys suggested me on this forum (thanks again !))) Then to test the validity of my setup, I decided to have a plc looking for rising edges of my base clock and when it sees one, takes the difference between the commanded motor.ActPos and the P0 registered at the start of the motion program and look at the modulo of this difference by step_size : (motor.ActPos- P0)% step_size I was expecting to see something centered on 0, with a large amount of jitter due to my measurment method (110 us plc). but instead I have something like that : modulo A |.......................W............................W...........................W |.......................WMMMMMMMMMMMW...........................WMMMMMM |.......................W............................W...........................W |-------------------W-----------------------W-----------------------W------------------ 0 |.......................W............................W...........................W |MMMMMMMMMW............................WMMMMMMMMMMMW |.......................W............................W...........................W |-----------------------------------------------------------------------------------> time each W vertical line happens during a U-turn, this seems norrmal, there is no reason for the modulo for being meaningful during acceleration and deceleration during constant speed paths, the error is not centered on 0 but has an offset, and this offset is different depending on the direction of my scan with a symetry .
  20. Many thanks, that is exactly what I was looking for ! have a good day !
  21. Hello, We are using the triggered time base to accomplish synchronisation with an external device. This device gives us 2 signals a 1kHz clock and a 128kHz clock perfectly in phase (<20ns jitter) we want to use the 128kHz signal as an external time base for one of our CS and use the 1Khz signal as the capture flag to defreeze the time base (at the next rising edge after arming) problem, the incoming signals are 5V so we plugged it on coder inputs of spare (dummy) motors. At first we thought that we could use ServoCapt.a in pEnc1 for the trigger instead of using the flags , but does not seem that this signal is unfreezing the timebase at a rising edge of a coder pulse (the coder is configured in pulse and dir) is there any way to use a signal wired on a coder input to trigger the time base ? (for now we are still trying to avoid to connect it on a flag input which would require a voltage adaptation) maybe by tweaking the pLimits adress ? Now what I tried to do is to put the capture flag as "always active" in the motor config so that it reacts "instantly to the arming" then I created a plc that arms the time base as soon as it sees a change in the integer part of the coder value (using a floor) I was expecting to see my time base unfrozen with an jitter proportional to the servocycle (110us). but again, it seems that I am completely out of phase , I presume the arming does not give me any real-time guarantee (aka if arming at servocycle N with an always up capture flag, then time base is unfrozen at servocycle N+1) . is that correct ? thank you for your help. regards, Jeremy
  22. Hello I am having the same issue, I recreated the directories but it still complains about missing files in the Configuration folder during the upload , and the save command although it says save completed does not save anything .
×
×
  • Create New...