Machsupport Forum
Third party software and hardware support forums. => PoKeys => Topic started by: Weerasak on March 13, 2015, 01:15:52 PM
-
Hello All,
I’ve found a problem on fast encoder channels 1, 2 and 3. it always gives incorrect counts. I also have tried varies speed start from very low speed to high speed. It always gives extra plus and minus counts depend on direction of jogging.
Is this a firmware problem?
However, on ultra-fast channel 26 was OK, the counts was always correct.
The way I conducted the test is that. Hit Zero button for all axes. Turn on and off PoKeys57E the counters will reset to zero, Then Jog away from zero randomly, then hit Goto Zero button, Mach3 will command motor back to zero point.
The purpose of doing this, because I would like to use an encoder to feed back position of commanded position. In general Mach3 with parallel port, at Ports & Pins>Encoder/MPG, I assume that we can set scale value in Counts/Unit column and it will show feedback of commanded position.
However, with PoKeys plugin, mapping an encoder1 to X encoder (DRO 29), The value of Encoder Position in tap Setting (Alt-6) will be the same as encoder counts which appears in status window of PoKeys Plugin.
Where can I set scale or Counts/Unit for encoder?
The feedback encoder is 1000 p/r and make a connection as shown in picture below, Plugin version is v3.1.51 (15.2.2015).
Pin mapping is here.
1 = 1.A
2 = 1.B
5= 2.A
6= 2.B
15=3.A
16=3.B
8=26.A
12=26.B
Thanks
Weerasak
(http://i389.photobucket.com/albums/oo335/vrasak/PoBobEncoder_zpsiuzv0sat.jpg)
-
Hi Matevž,
Here is the operation on channel 26, everything is OK. But on fast channels is Not Ok. Please find out.
http://www.youtube.com/v/IFPw3kvAUns?hl=en_US&version=3&rel=0
Thank you,
Weerasak
-
I also found more problem on plugin version 3.1.47b and 3.1.51
(1) step per unit, if you put decimal point more than hundredths will cause motion problem and limit signal triggered, for example put number 400.1234, it seems that plugin will need more time to calculate step signal
(2) dual drive, may be because of problem (1) that makes master and slave not synchronize and result in jerking gantry.
-
The problem is that all the motion calculation is done by Mach3 code by itself (disregarding the jogging motion) and PoKeys only executes the commanded moves (which are in the format of integer number of steps per each 1 ms timeslot).
-
We're always comparing other plugins with parallel plugins. I don't know what happen when I put more and more decimal point in step per unit, the system get slower and slower during jogging and there are abnormal events during running, Please experiment this issue.
-
So, is the issue related to jogging only or to job execution also?
-
So, is the issue related to jogging only or to job execution also?
Below was a situation we had faced.
The issue related to step/unit. we put following number
407.4357 >> worse, jog very slow <this number is work fine with parallel port system before)
407.436 >> jog move better , but not fast as normal ( normal = parallel port)
407.44 >> jog fast as normal, but some time Y1 and Y2 not synchronize result in jerking (Y2 is slave axis) -
After customer and I tried hard to installed, learned to replace parallel port system with brand new PoKeys , We agreed to get rid of jerking problem by writing VB script to control a DPDT relay to switch back and forth signal for Y2 motor driver. During homing, we let Y2 have its own signal ( Y1 and Y2 both have their own homing signal). During normal run, we let Y2 to obtain Y1 step/direction signal.
After several hours of trial and error with PoKeys57E, we thought that reached to expectation and calm situation, all everything seem to work fine, then We let night shift operators to handle their job as usual.
Next morning, I got the report that operators experienced Mach3 stop working occasionally and present execution line is reversed back to beginning. However, I made a test at my office in another day (dry run, not motor driver) and found that only Limit signal is triggered occasionally, which possible that the night shift operator had encountered this issue and did not know how to handle and made a wrong report.
Same morning, Then we decided to remove PoKeys from the system just for time being and reinstalled parallel port system back in place.
The answer to your question is Both.
-
BTW, any progress on Fast Encoder channels!
Have you tested?
-
I found the same problem in steps/unit with pokeys 56U.
If there was a decimal number in steps/unit, jogging and running did not work correctly.
If I left a full nr, with no decimal, it was ok.
I did not notice if the amount of deecimals was relevant.
This is with parallel port.
This leads to an error, of about 0.1%, on my systems.
I have not yet tried this with servos - but will be trying this soon with 57E+cncaddon.
It may be that with servos, I do not see the error - because they react so much faster than steppers.
The error was very, very noticeable with steppers.
This same error re:decimal units did not appear with smoothstepper (many years ago), or with centipede motion controller (last year).
Both tested in mach3, different machines/pcs/installs, so its inlikely it was an install problem.
-
BTW, any progress on Fast Encoder channels!
Have you tested?
I'm sorry to rush you! The developers are in the middle of two side war, one is Mach3, another is Mach4.
I'm glad to see you roll out new plugin and manual for Mach4.
PoKeys Mach4 plugin 1.5.2/1.2270 + manuals (24.3.2015).zip
Thanks so much for keeping up the awesome work.
-
We are quite busy working on the plugins and have little time to check the forums - our official support is only through emails at the moment.
We will check the issue with the decimals. Since the translation from floating point numbers to integers is done on PC (either in Mach3 or plugin), I am hopeful that this can be solved.
-
We have now fixed the problem with the decimals - up to 3 decimals are now allowed. Download the update 3.1.52b for the new plugin.
The plugin constantly monitors the motion parameters of Mach3 and compares them to those in PoKeys device. If parameters differ, they are updated. Specifying step value in decimals caused the plugin to constantly detect the change (due to rounding error) and was updating the parameters in device constantly, blocking the motion as the result.
-
I’m back, after been away for Songkhran (Thai New Year) holiday for several weeks.
I tested plugin version 3.1.53, the decimal point problem is gone. However, Fast Encoder problem still there, counter is not correct when compare to Ultra Fast Encoder . even I perform slow jog.
-
Originally, encoders support was designed for use with simple encoder switches (without a numeric dial). The fast encoders were later added for use with MPGs and not for providing position feedback of the stepper (ultra fast encoder can be used for this purpose).
-
Hi,
From my opinion speed of fast encoder (hardware interrupt, but not dedicated one) should be able to handle this, we can notice from the pace of counting and few error of counting.
There should be a bug need to be addressed. I know that finding this mysterious bug is not easy.
I'm sure you guys can do it, It's just a matter of time.
Thank you for your work,
-
As I noted earlier, these encoders were not designed for such job. Even interrupt events are a limited resource and a lot of other functionality can affect the performance of fast encoders (Pulse engine operation, PoIL core operation, communication, etc.).