EPEC - did you try it?

[Armando]

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

[the_lizardking]

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,...

[Armando]

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

[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

[Armando]

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

[sleepwalker]

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).
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

[the_lizardking]

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?

 

[Armando]

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

[Armando]

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

[Tobias]

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.

[the_lizardking]

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.

[Armando]

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

[Tobias]

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

[Armando]

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

[Tobias]

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!

[Armando]

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... 

Clear Skies!
Armando

[Tobias]

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 ...
CS Tobias

PS Is it (the news) worth a sticky?

[Armando]

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

[Tobias]

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....

[Armando]

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