Jump to content
OMRON Forums

jsinoir

Members
  • Posts

    22
  • Joined

  • Last visited

jsinoir's Achievements

Apprentice

Apprentice (3/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  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
×
×
  • Create New...