LittleFoot Elegance Photo Community Forum
LittleFoot Elegance Photo => LittleFoot Elegance Photo => Topic started by: Armando on Wednesday, 03.04.13 - 16:35:23 - CEST
-
Hi @all,
I'm tempted to test EPEC: I think it's the main LFEP feature. Unfortunately I think nobody, including Rajiva, tested it.
Orlando Andico is developing a cheap board to allow RA ST4 corrections by an RA encoder feedback (a sort of cheap TDM alternative).
Anyway if LFEP EPEC is not affected by any bugs I would suggest an interpolator to convert analog sine outputs to TTL ones: LFEP should make the rest. It could be simpler than a "TDM style" board: no timing/oscillator issues, no ST4 outputs, no ST4 inputs, no need to correct anything, just the need for a signal conversion... LFEP should make autoguiding possible with guiding exposure times of 30s (or more) with cheap guiding cameras on OAG too!
In case of limited capabilities of the MCU used to convert the encoder sine outputs, EPEC could be automatically toggled by ASCOM driver when a GoTo command is sent. I think also that angle computations could be avoided: storing and comparing (by a LUT) tg or ctg values could be enough...
So the only expensive part is the encoder because of the need of 5000 cpr and adequate accuracy.
Did you try EPEC?
I'd like to avoid to buy the encoder and make an interpolator just to discover that LFEP EPEC doesn't work at all (because of LFEP firmware bugs). I would appreciate a confirmation that LFEP is really able to manage EPEC. ::)
I found on the old forum some attempts to use a gearbox to connect a low resolution encoder with no need to opt for sine rotary encoder and interpolators... I perfectly understand a gearbox is not a good starting point but if these attempts failed simply because of gearbox issues I think it's worth trying to build an interpolator...
What do you think about this idea?
CS
Armando Beneduce
-
Before going to buy any encoder I could test EPEC by emulating the encoder outputs by a PIC MCU...
I could check if RA speed increases/decreases by applying square wave outputs with variable frequency around the "expected sidereal" one...
I hope the LFEP controller is able to "follow" huge errors (i.e. keep memory of many missing or excess signal edges).
Anyway, before going on, I need to know if I can connect the PIC MCU output pins (used to emulate the square wave encoder outputs) directly to LFEP encoder input pins with no resistors at all. Are LFEP encoder inputs TTL ports?
CS
Armando Beneduce
-
I just made some tests by emulating an encoder (1M ticks)...
With EPEC disabled I can see that RA encoder position (shown by the display) follows the emulated speeds.
If I enable EPEC and intentionally emulate a wrong (high) speed, after some seconds tracking speed decreases. But, as soon as this happens, if I emulate a low speed the mount speed is kept low.
The same happens with a wrong (low) emulated speed: tracking speed increases but if I emulate an high speed the mount speed is kept high. :(
I tried also to emulate different speeds by gradually increasing/decreasing the starting sidereal one but unsuccessfully.
I should make some tests on a star but frankly I'm a little disappointed. ::)
CS
Armando Beneduce
-
Hi Armando,
thank you for your tries... too bad that it don't work well :( .
I had some discussions in the old board with a member, which name i have forgotten, about possible encoders. I have a Canon encoder with 50 000 ticks here and we have sheltered that there is no possibility to create a transmisson without enormous erros like temperature-drifft and so on.
So we thought an Sinus-magnet encoder could do the job if there were the possibility to help the accuracies with some statistics...
If the epec didn't work well I see no option how to implement it without the firmeware-code. Or we had to fabricate a box which tells the LF to make a GoTo many times per second.... so it would block the connection to other programms nearly completly I think.
Have you other thoughts?
CS Tobias
-
Hi Armando,
Please excuse my bad english first. The English language and I are not best friends. :-[
Thank you for your tests. They are not positive, but very helpful.
I have got a "Renishaw" Encoder (RGH34 + 400mm measuring tape).
I achieve a resolution of 0.7 arc seconds so. That should be enough for EPEC.
The adaptation to the axis is not yet completely finished.
I also have a 3300 AEDA with 20000 ticks tested and found that only 1 revolution per second (that is 20,000 ticks / s) are possible with the LFEP. with faster turn the LFEP doing a reboot. The GOTO positions are then gone.
When I sometime mounted the Renishaw encoders, it is only possible to rotate (by hand) for less than 10 degrees per second.
That is very unfortunate. :(
Also I can not test EPEC, because I do not have the PEC -Tracker and also do not know where I can get it. Do you know where I can find one?
Maybe I need 2 encoder on the RA-Axis. One with less resolution for GOTO.
And the second for EPEC. I do not know the project of Orlando Andico. But maybe that's the better way.
I hope you can understand what I mean.
CS, Dennis
-
Hi Tobi,
ich denke, das war ich ;)
CS, Dennis
-
Hallo Dennis,
ja das warst du! Da ja die PNs nicht mehr aufrufbar sind... war ich mir nicht mehr sicher - sorry. Schön, dass du hier nun auch aktiv bist, so können wir da evt weiter machen - falls sich etwas ergibt.
Cs Tobias
PS Gut, dass du die Encoder noch nicht gekauft hast, da ja scheinbar der Epec nicht funktioniert… wäre schon schön gewesen.
-
Hi Dennis and Tobias,
if EPEC doesn't work then a TDM style solution could be used: I think ST4 is the only way to properly manage the encoder feedback.
Anyway, even if more versatile and not limited to LFEP, a TDM style board is difficult to be realized. It will also oblige to guide by ST-4.
During the autoguiding exposure it should send its own ST4 corrections; while receiving ST4 corrections the board should use encoder feedback to keep a different speed (e.g. 1x+0.33x or 1x-0.33x) : this way it will effectively track also the correction.
I think enabling autoguiding is a requirement, also in case of an ideal polar alignment: it should solve possible integral errors caused by oscillator frequency issues and by the same encoder limited accuracy.
Orlando Andico published on CloudyNights his attempts to make a feedback by a sine rotary encoder useful to reduce the tracking error (with no autoguiding). But some troubles occurred because of possible PE due to the encoder itself!
We could prefer the EPEC by converting sine outputs to TTL ones. In case it won't work we will be obliged to switch to a TDM style solution.
I think currently it's not priority to take into account possible encoder feedback issues while the mount is slewing or because of a movement by hand. In the worst case a quick solution will be to provide a command to toggle EPEC off/on by ASCOM driver (and automatically for GoTo commands).
If LFEP is able to track 20000 ticks/s I see no encoder reading issues at all at sidereal speed.
What I'm not sure is EPEC. As a 5000cpr encoder is not cheap at all, do you think it's worth it?
AFAIK EPEC option is enabled by an appropriate firmware update.
I bought my LFEP unit with all options enabled; afterwards Rajiva announced the end of the LFEP support.
CS
Armando Beneduce
-
According to the noise coming from RA motor (by assuming that EPEC works by moving RA motor at 1x+0.33x or 1x-0.33x) I found that simulated high (resp. low) speed forces LFEP to decrease (resp. increase) tracking speed.I see no troubles while switching between sidereal and lower speed. But as soon as the higher speed is activated the controller remains locked at that speed. :(
I've no way at home to check by a telescope.
CS
Armando
-
Hi Armando,
The encoder error is not unimportant. My encoder has a maximum error of 60% per tick. This is a half arc second. I think that is tolerable. Also should not be used as a gearbox in order to increase the resolution. It makes no sense to try error of gears with other gears to fix.
It is not only the polar alignment. The stiffness of the mount against wind and vibration as well as the bending of the telescope itself must be minimized.
The bearings should have no gap and have to run very precisely.
(1 arc second are only 1mm at 200 meters)
These are very high demands on a payable mount.
My mount is a self made with 60mm diameter axis and handles very precisely.
My encoder is an optical non-contact encoder ring. Thermal expansion is not a problem.
If only I could somehow get the EPEC option for testing.
Is there really no more updates? :'(
I think that there should be a way to improve the EPEC.
It can not be so difficult to influence the speed of a stepper motor controller.
5000 tpr are not quite enough. With quadrature you have a resolution of 65 arcsec.
(1296000 "/ (5000tpr x 4 (quadrature)) = 64.8")
And then comes the potential errors in the Enoders ...
What annoys me with the LFEP: an encoder that allows EPEC, makes no GOTO by hand.
No matter if TDM or LFEP, I need currently 2 encoder on the RA axis to have both.
Perhaps there is a way (with additional box) to save the tick and leave in a specific maximum speed to the LFEP. GOTO by hand is then slower but doable.
CS, Dennis
-
Hi Dennis,
the 5000 cpr encoder I'm referring to is a transducer with analog sine outputs (and 5000 sine periods per revolution).
By a differential ADC for each differential output channel it's possible, with appropriate interpolation, to achieve the required resolution (e.g. by opting for 512 samples/sine period a resolution of 1296000''/(5000*512) = 0.5'' is possible). Even if, according to Heidenhain specs, accuracy is limited to 1/20 grating period, as TDM solution works as expected and makes use of the same encoder I'm referring to, I think it's possible (but also difficult) to effectively reduce PE. Probably the accuracy is the overall one that takes into account also the integral error. By making use of an autoguiding system this limitation won't cause any issues since the integral error is minimal on a short guiding exposure...
The IBV660 B interpolator by Heidenhain with a 400x interpolation (1600 by taking into account the quadrature) should confirm that it's reasonable to force an huge interpolation (i.e. to achieve good resolution).
I think your encoder requires reduced eccentricity; we could prefer it because of TTL outputs with no need to interpolate any analog outputs... Anyway I think that currently EPEC doesn't work.
As for GoTo, the I2C interface can allow us to avoid the use of 2 RA encoders: an ASCOM command by I2C can command the board to switch to "low" resolution mode. Then wrong RA coordinates can be managed by ASCOM according to the high/low resolutions ratio...
The board in low resolution mode could limit itself to count the sine periods. Anyway I still think GoTo limitations are marginal.
But making a TDM style controller is not a joke... ::)
CS
Armando
-
Hi Armando,
I also gave the EPEC a try.
The RA drive of my scope is a homemade steelbeltdrive. It works great. Here is a link to some photo's i made from the EPEC trial more then a year ago.
https://plus.google.com/photos/117395768557029373537/albums/5864006567181203345
As you can see, i mounted a 5000 tics encoder on one of the guide-rolls of the steel belt. (20.000 quadrature)
Because the resolution is waaaay too small for mounting it directly on the polar axe. But probably the total resolution of the encoder is still not big enough.
Every time i switched EPEC on, the motor started a correction in +0.3 siderial.
I did a lot of measures with an oscilloscope and two electronic counters. But finally i gave up, dissapointed of course.
I asked Mr Rajiva some questions about it, and he promised to look at it in the future.
But now we know he gives no support anymore. That's a sad thing. :'(
But as i said before i respect his deciscion.
Best Regards
Antoon
-
Hi Antoon,
I also found EPEC, some seconds after the activation, caused 1.33x guiding.
So I tried to tune (iteratively) the emulated encoder outputs frequency to have no RA coordinates drift. I didn't check by a scope the (emulated encoder) output frequency and because of the annoying computation of PIC18 ISR overhead and possible frequency drift I preferred to take into account RA coordinates shown by the handbox display (with EPEC disabled) to define the square wave output frequency corresponding to sidereal speed (according to LFEP :P)...
Then I found that higher and lower frequencies made EPEC apparently working. But as soon as 1.33x (or 1.66x) is activated by EPEC I see that the controller remains locked at that speed.
Because of 1.33x speed activation as soon as you enable EPEC, I think your test is a confirmation... I think you can also notice RA encoder coordinate drift (with EPEC disabled).
Could you make a similar test? As you obviously can't change encoder resolution, could you check by entering (iteratively) an intentionally wrong encoder resolution by the handbox? I'm suggesting to iteratively tune a (wrong) encoder resolution...
Then you could enable EPEC and let us know what happens...
CS
Armando
-
Antoon,
be sure also the encoder output wires are not to be swapped...
-
Hi Armando,
Sorry for the late answer. I've been very busy the last few days.
You said ; "be sure also the encoder output wires are not to be swapped..."
I'm sure this was not the case. I tried all combinations. :)
You also asked; "Could you make a similar test? "
Unfortunately i must say no, Sorry ! I sold my encoders to a guy who bought the servo controller from "SIDERIAL TECHNOLOGY" (Mel Bartels)
He used them for his mount with DC servo motors.
As i said i gave up because Mr Rajiva mentioned somewhere on the old forum to use encoders of at least 648.000 tics.
This is what he wrote;
my calculator ... , 648000 Ticks (not counts) is correct for +-1 arcsec http://en.wikipedia.org/wiki/Minute_of_arc#Symbols.2C_abbreviations_and_subdivisions
CS
Rajiva
I mounted my encoders on one of the drive rolls of my mount. A little measuring and calculation learns that i had only 74.117 tics.
So way too little. And such encoders (if they exist) cost probably more then the entire LFEP. ;)
Now i'm working with an autoguider, and that works ok for me.
Best Regards
Antoon
-
Hi Antoon,
Sorry for the late answer. I've been very busy the last few days.
Thank you for your reply. ;)
You said ; "be sure also the encoder output wires are not to be swapped..."
I'm sure this was not the case. I tried all combinations. :)
;)
I mounted my encoders on one of the drive rolls of my mount. A little measuring and calculation learns that i had only 74.117 tics.
So way too little.
Yes, 648000 tics or more are required to enable EPEC.
And such encoders (if they exist) cost probably more then the entire LFEP. ;)
This is the reason why I think a sine rotary encoder is required together with an home made interpolator. And by this combination the encoder would be no more than 350 Euro.
Now i'm working with an autoguider, and that works ok for me.
I don't mean to replace an autoguiding camera by an encoder. I'd like to add support for an encoder feedback during the autoguiding exposure to achieve the best tracking performance...
Anyway I'll take my time to evaluate if it's worth it (there is also another reason why I'm tempted to enable an encoder feedback: PEC could help to improve tracking during long autoguiding exposures (i.e. more than 5s) but I found a not integer reduction ratio on my new SynScan coupling that makes PEC no more useful. >:( Maybe I'll replace the gears by a belt/pulley transmission to improve tracking and to have a 5:1 reduction. Then replacing the RA motor by a new one with 0.9° step angle could help to further improve tracking.
CS
Armando
-
Hi folks,
not sure is the software already downlaodable - I do not have the feature EPEC activated so I would need to update my LFEP first - encoders are there.
cheers
-
hi,
I also have no idea where we can get the update for EPEC-option. :(
If mr Rajiva publishes the software (as he promised), perhaps we will find someone who takes a look at EPEC, polar alignment and the other things which do not work now.
My complete optical encoder cost 400 euros (including 19% tax). :P
http://www.renishaw.com/en/rgh34-linear-encoder-system--6450
The measuring tape can be glued to a ring with a diameter of 125mm or larger (approx 393mm length).
I have the type: "RGI34W" and achieve a resolution of 0.66 arcsec (0.002 mm x 392.7 mm = 1.963.495 tics/revolution (TTL, quadrature inclusive)).
I still have to build a case and a 125mm ring with fixation on RA axis.
The service Renishaw told me that temperatures less than 0 ° C are in order, if no condensation occurs.
(This design of the encoder are also used by ASA-mounts.)
I think this encoder and EPEC (if it works at some point) are still much cheaper than a good gear and a precision worm gear.
Armando:
Now I understand your statement about your encoder resolution. Thanks for that.
My problem is still that I do not have a second Encoder on the RA axis for GOTO by the hand (no space). So I need a hardware or software that buffers the encoder signals and pass it with 20000 Hz or less to the LFEP (for example).
CS, Dennis
-
Really good idea to use linear encoders, so you can build this tapes for less money,... testing the things will never be the problem,... theres always someone who uses this features - I use both if needed to be tested :-) maybe someone of our mechatronics picks this idea up and build the missing interface for you. It sounds like a practicable solution that should be published for everyone.
However for testing EPEC the DEC encoder is good enough, I also have a smaller one in RA axis for goto,... it looks for me that it works almost stable for GoTo so far. But I always have some smaller troubles with it that I cant locate or project to either the complete setup itself or the encoder function. Some support and two oppinions would be great in this section... as it is a complex topic.
Lets see what future brings up, I hope Rjiva will find the time to support us with the software once, I think its a huge work to upload everything and make short infotexts for each,... so it will take some time to do so.
-
Armando,
also Inducoder is a cheap option,... I have one with 80000 tics using a 16x quadrature (4x internat and 4x gear) with a beltdrive and it works fine with a TDM test. Of course there are some failures from encoder but with this resolution it can be resolved by the technic itself.
I also bought my LFEP with all options and I thought EPEC would be includued, otherwise I would have bought encoder option,... but no epec. In a perfect world we live heheh some have encoders but no epec other have epec but no encoder :p ... I do not know how but we should overcome this oneway road situation and should have a GNU License version of the firmware to update all LFEPs with all options opened.
-
Hi the_lizardking,
I agree with you except for one aspect: I would have kept the old MCU update kit and avoided the LFEP if I had known that EPEC doesn't work...
CS
Armando
-
I was reading your first entries regarding the bugreport and I was thinking about it. From my point it does not really look like a bug at this point. If this problem really pops up with 1,33x speed you can discard it,... and put it in tales for hardcore testing :-)
If you really use an encoder with 800K it wont be needed to use such a speed to make correction, 0,5x in maximum should be enough,... with 1,33x you will pass a lot of lines or inductions during move and could be that the encoder routine simply states this encoder has not enough lines to be used with EPEC and stops,...
-
Hi the_lizardking,
I tested EPEC with the mount locked and by emulating the encoder output.
By 1.33x I mean 1x (sidereal speed) + 0.33x.
Before testing EPEC I assumed it was more sophisticated and not limited to guide at the usual guiding speeds but according to the position feedback...
Then I found it moves the mount as usual and unfortunately locks as soon as 1x+0.33x is active too.
CS
Armando
-
Hi @all,
Rajiva released a new firmware update and published a message to notify us that FW update engine is now on. It will be probably the last FW release. Also CU FW is involved (6.30); maybe EPEC has been modified.
I'll check in the next few days if the update affects EPEC.
Obviously I'll still make use of emulated encoder output to see how LFEP reacts... So, in any case, I can't state with absolute certainty that EPEC doesn't work; but I'll keep you informed in case I'll have found some evident EPEC changes.
CS
Armando Beneduce
-
HI @all,
I gave another look at EPEC. I found substantially the same behaviour. :(
In a few words with reverse RA axis:
normal <-> high speed switches occur as expected
normal -> low speed switch occurs as expected (maybe with too high delay)
low -> normal speed switch never occurs
With normal RA axis:
normal <-> low speed switches occur as expected
normal -> high speed switch occurs as expected (maybe with too high delay)
high-> normal speed switch never occurs
I tried different guiding speeds but nothing changed, except a simplified debug with reverse RA axis that showed RA motor locked because of the missing low speed (i.e. stopped motor) -> normal speed switch...
With EPEC disabled, encoder coordinates shown by the display change as expected (i.e. increase, stay constant or decrease as expected). So I'm sure LFEP is able to read the low, normal and high emulated encoder outputs @1000000 tics (4000000 with 4x interpolation).
So I think only EPEC is affected by a bug. I hope Rajiva will give a look at EPEC. I'll obviously make any kind of test if required.
CS
Armando Beneduce
-
Hi Armando,
I tried to apply the new update. There comes the message that it is not yet available the "Update Engine".
I had hoped that Rajiva would publish all the software so that everyone could use and improve it.
Armando:
I think the number of counters is not a problem for the LFEP.
At a resolution of about 1 "(1.3 million ticks with quadrature), there are 15 counts per second in sidereal tracking time.
That's no problem at all.
But the speed with which the signals arrive, if you turn fast GoTo or rotated by hand. Already pans of 20 degrees per Timesecond lead to 1.2 MHz (in one axis only). :o
The LFEP to my knowledge, has a Chip with 1.5 MHz.
This is very low, if other applications need to run simultaneously.
I have observed that even LFEP failed and rebooted if the encoder turned with little more than 20000 tics per timesecond (80000 quadrature).
The engines stopped and the connection to the laptop was gone.
And the GOTO position of course .... :(
I would recommend not to use more than a resolution of 1 ".
Even then pans are possible with a maximum of 10 ° per (Time-)second.
Much more important than resolution is the accuracy of the axes bearing and encoder.
When you use a gear unit, then 0.001 mm deviation are often several arcseconds at the encoder.
To avoid malfunctions should be omitted gear units.
CS, Dennis
-
OK but 1" would be enough to improve tracking I think, when the best possible seeing is 2 or 3" in average. We want to improve PEs that are more than 3" in movement,... or do I understand smth wrong here?
-
Hi Dennis,
obviously in my last message by low and high speeds I meant 1X-0.33X and 1X+0.33X (or 1X-0.67X and 1X+0.67X or 1X-1X and 1X+1X).
By speed lock I meant LFEP was locked on low (or high) guiding speed (i.e. with + or - RA correction always active).
Are you suggesting emulating a 324000 tics RA encoder?
I'm pretty sure the same EPEC lock would occur.
CS
Armando Beneduce
-
Hi Dennis,
I just emulated a 324000tics encoder. Nothing changed.
As for the update engine I found a new message by Rajiva according to which I think (the message is only in German) the update will be possible next week.
CS
Armando
-
Hi Armando,
yes Anand wrote, that next weekend the Updateengine should work again - it is shut off since the power failure while working on the electrical system.
Because he typed also that there will be no additional informations thanks to disputes with some manufacturer, with informations i think he means firmware etc, the EPEC-problem will only be solved through a external Box... too bad.
To your Epec-Testings:
Thank you very much for your diverse tries! If my understanding of your conversation is correct the LFEP is stucked in the correction-movement after detecting that an divergence to the reference position implies a movement? If you think that there can be a problem by your signal-emulation i could try to search for a currently unused signal generator in my University.... but I think it isnt worth it because there is a bug in the programcode and not your construction.
CS Tobias
PS: Please excuse my english - I have often heard that it must be terrible.
-
I think we should no longer spend time on this, its simply not working,... we should concentrate to either leave it or create an external box.
-
Hi Tobias,
To your Epec-Testings:
Thank you very much for your diverse tries! If my understanding of your conversation is correct the LFEP is stucked in the correction-movement after detecting that an divergence to the reference position implies a movement?
In a few words, with normal RA axis direction, if EPEC has to compensate a slow speed it commands an higher speed (as expected) but then it never reverts to normal or slow speed...
I was hoping that swapping RA wires would have solved the issue. But with reverse RA axis direction, as soon as EPEC has to compensate a too high speed, motor starts rotating at low speed (as expected) but unfortunately remains locked at slow speed...
If you think that there can be a problem by your signal-emulation i could try to search for a currently unused signal generator in my University.... but I think it isnt worth it because there is a bug in the programcode and not your construction.
Now I'm sure the encoder emulation is right. :(
I can see encoder coordinates change accordingly when EPEC is disabled. The same doesn't happen with EPEC on.
Setting any encoder resolution on LFEP and emulating the corresponding outputs with no need to finely tune them confirmed LFEP encoder readout and my PIC board work accurately (e.g. with 1Mtics resolution - 4Mtics with quadrature - and by emulating sidereal speed on both encoders the display showed exactly 1° movement on Dec after 4' and 0s and no RA coordinate drift).
PS: Please excuse my english - I have often heard that it must be terrible.
Thank you for writing in English! ;)
CS
Armando
-
Hi all,
sorry for my late answer; i were reading this post nevertheless ;) .
I have stumbled over one thought, perhaps I have missunderstood some thing but perhaps I'm right and perhaps after all the Epec works correct.
You have simulated a encoder signal with the right frequences, right? Then you have changed the frequenz for example a bit lower. The LFEP recognized the error and began to correct.... then you changed the frequency to the normale state und the LFEP moves still in correction-mode?
Now my point: During this simulation the "star" have changed the position - at least this thinks the LFEP- , so the LFEP keeps going to correct this failposition. Therefore you had to change the enocder-frequency to the suitable faster rate and suitable duration, so that the LFEP thinks that the star is on his correct position. Have you done this? Perhaps this was our mistake.... ;)
But perhaps i have missunderstood what you have tested already und EPEC is bugged at all :( .
CS Tobias
-
Hi Tobias,
You have simulated a encoder signal with the right frequences, right? Then you have changed the frequenz for example a bit lower. The LFEP recognized the error and began to correct....
Yes
then you changed the frequency to the normale state und the LFEP moves still in correction-mode?
I already changed also to the "opposite" wrong direction... ;)
While testing (to take into account possible bugs) even toggling encoder direction (that should never occur at 0.33x, 0.67x and 1x guiding speeds) didn't "unlock" EPEC.
CS
Armando
-
Hi Armando,
ah so although you simulated the opposite direction for a long time the LFEP drives the motors in the direction from beginnen?
Than I think the EPEC is truly buggy... :(
CS Tobias
PS Thanks for your tries!
-
Hi Tobias,
Than I think the EPEC is truly buggy... :(
It's worth telling that Anand Rajiva opened parts of the firmware for further development. Only some users will be able to receive the source code. The development is already in progress even if Rajiva is no more involved.
A bug has just been identified and EPEC code is going to be modified. ;)
So stay tuned... 8)
Clear Skies!
Armando
-
Hi Armando,
THIS IS AN AWESOME NEWs!
Its sad that the LF didnt morphs into an open source project so that everyone can build one.... thankfully i have a lfep allready ;) . But its nice for the bereaved that there will be the possibility to improve the features and erase the bugs of the LFEP. A big thank to Anand that for this chance ... and I think there are not so much persons here which have the ability to write the firmware, therefore its not the big deal that only a few are allowed to do so.
This news made my day :D ...
CS Tobias
PS Is it (the news) worth a sticky?
-
Hi Tobias,
Is it (the news) worth a sticky?
I mean to test by my encoder emulator EPEC as soon as a new (beta) FW will have been released.
In case of successful tests I think a sticky topic will follow. ;)
Then we should opt for a test by a real encoder...
CS
Armando
-
Hi Armando,
oh sorry that wasn't what I meant!
I applied to create a sticky for the news that there is the possibility to improve the firmeware; not specific the EPEC ;) . Its a big news, after Anand said that he is off and the firmware would not be open...
I think that others want to know equally that "we" can modify the firmeware now; restricted but anyway possible ...
CS Tobias
PS Encoder.... I think this is a big new post which one are useful and affordable and which one needs an additional circuit....
-
Hi Tobias,
I applied to create a sticky for the news that there is the possibility to improve the firmeware; not specific the EPEC ;) . Its a big news, after Anand said that he is off and the firmware would not be open...
I think that others want to know equally that "we" can modify the firmeware now; restricted but anyway possible ...
Fixing other bugs requires the availability of the related FW source code...
Till now I received only parts of the source code related to EPEC and I identified a bug that is surely related also to EPEC stall.
I'm mainly interested in EPEC because high resolution encoders are not cheap at all and maybe someone already bought one of them or modified his mount to properly mount it...
Encoder.... I think this is a big new post which one are useful and affordable and which one needs an additional circuit...
LFEP supports only digital encoders. The main EPEC requirement is an adequate resolution (< 1asec).
The restrictive resolution makes reductions not applicable. So the encoder itself should offer a resolution of no more than 1asec.
Unfortunately an angular speed of 360°/day is not common at all. And at high angular speed a digital rotary encoder with 1asec resolution is not available because of bandwidth limitations. This is the reason why opting for a rotary encoder obliges to use an encoder with analog outputs. In this case an interpolator is required to obtain a digital output supported by LFEP. There are ready-to-use interpolators but they are not cheap because they offer good resolution at high speed too. And we have less restrictive requirements. This could suggest to opt for building an interpolator without support for high speeds...
The alternative is the use of (Renishaw) angle encoder rings. But mounting a Renishaw ring is critical because of possible eccentricity errors.
I think the simplest solution is a rotary encoder with analog output together with a ready-to-use interpolator. But I suggest to be cautious: only when my encoder emulator will have confirmed EPEC is (apparently) working as expected a test on the field (by a real encoder) will be required.
CS
Armando
-
Hi Armado,
I am pleased about the good news that it is going ahead.
Thanks for your work.
But I think compliance with the tolerance of the ring is not that difficult.
of course the axis should run "round" for EPEC.
The lateral tolerance is at least 1mm (+/- 0,5mm).
0.2 mm and 1 ° axial tolerance should be doable with a simple lathe.
See here for Renishaw-Data:
http://www.renishaw.de/de/rgh34-lineare-wegmess-systeme--6450#ElementMediaList12280
The ring may indeed be adjustable. Just as with me.
Unfortunately, I have already the interface with 0.2 my resolution (digital).
I hope, therefore, that it is also possible to buffer rapid signals of high-resolution digital encoder during rapid rotating the RA axis somehow.
So I can do the meridian-switch by hand and do not wake up the neighbors. (My motors are very noisy at 420x)
best regards, Dennis
-
Hi Dennis,
But I think compliance with the tolerance of the ring is not that difficult.
of course the axis should run "round" for EPEC.
The lateral tolerance is at least 1mm (+/- 0,5mm).
0.2 mm and 1 ° axial tolerance should be doable with a simple lathe.
See here for Renishaw-Data:
http://www.renishaw.de/de/rgh34-lineare-wegmess-systeme--6450#ElementMediaList12280
The ring may indeed be adjustable. Just as with me.
I would be tempted to prefer a Renishaw solution to keep the polar scope and avoid the interpolator. But I should figure out if the RA axis displacement that occurs when locking/unlocking the mount on RA can be managed. I own an EQ6...
I'm also not sure the displacement is always the same: both outer surface of the "cylindrical" body of the worm wheel and the inner bearings can contribute to a not constant displacement.
I also have no idea where to place a Renishaw ring on my mount .
What diameter is your ring?
Unfortunately, I have already the interface with 0.2 my resolution (digital).
I hope, therefore, that it is also possible to buffer rapid signals of high-resolution digital encoder during rapid rotating the RA axis somehow.
So I can do the meridian-switch by hand and do not wake up the neighbors. (My motors are very noisy at 420x)
I would suggest to use a lower speed. I'm not impressed at all when I see a mount moving at high speeds. I prefer a good tracking mount.
CS
Armando
-
Hi Armando,
the only place that I see on the EQ6 for a ring encoder, the scale for the celestial coordinates.
Whether the change in displacement is still within the acceptable range, you have to measure.
But perhaps it would be advisable anyway to customize this mount . ;)
There are thin plates and liners (PTFE). So that you can reduce or eliminate the gap.
My ring has a diameter of about 125mm. That is the minimum Renishaw said.
Slower speed for GOTO and Meridian switch?
Well ... I actually bought the Encoder Option, in order not to lose alignment when I release the clamping of the axis.
And now, with high resolution encoders crashes down the LFEP when I move the telescope without an motor.
This is not acceptable. And if I have to let the motors run slower, so that the birds do not fall from the trees at night, already not. >:(
I am now looking around for an electronic buffer ("Data Cache" or so).
The part should store the signals and pass so slowly to the LFEP that such is not overwhelmed. I think that a stroke of about 200 - 400kH would be optimal.
Unfortunately, I am absolutely Unknowingly in electronics and need help.
CS, Dennis
-
Hi @all,
I just opened a new thread about the firmware development. Unfortunately no good news...
http://forum.lfep.de/index.php/topic,38.msg273/topicseen.html#msg273 (http://forum.lfep.de/index.php/topic,38.msg273/topicseen.html#msg273)
Clear Skies!
Armando Beneduce