When using manual control the home status is not updated about firmware

[NameOfTheDragon]

I can't initially reproduce this. Is there something special about the numbers or does this happen from any starting position?

[rpineau]

On 07 Dec 2019, at 11:45, Tim Long ***@***.***> wrote: I can't initially reproduce this. Is there something special about the numbers or does this happen from any starting position?

It at least happen if the starting position is home. It probably happen also if you go home, then move the dome “by hand” using the rocker switch, the do a go home from the serial port ( @ghr )

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#25?email_source=notifications\u0026email_token=AAHEDIMVN6LLD2KCFMZNQVLQXP4O3A5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGOARQ#issuecomment-562880582", "url": "#25?email_source=notifications\u0026email_token=AAHEDIMVN6LLD2KCFMZNQVLQXP4O3A5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGOARQ#issuecomment-562880582", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

-- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ |

[NameOfTheDragon]

OK thanks.

So looking at the code, it is difficult to see how the homing operation can fail to start.

void HomeSensor::findHome(int direction)
	{
	if (phase == Idle || phase == AtHome)
		{
		const auto distance = 2 * homeSettings->microstepsPerRotation;	// Allow 2 full rotations only
		setPhase(Detecting);
		motor->moveToPosition(distance);
		}
	}

The only possibility I can really see there is that the phase state variable must be in the correct state or homing will not start. Perhaps the state is getting left in a corrupt state from a previous operation. This will need further investigation.

Home detection is via an edge triggered interrupt from the home sensor. Even if this were happening immediately after starting the home operation before the motor has taken even a single step, then that could possibly look like nothing has happened. This seems unlikely though, with a nearly 20 degree movement away from home.

[NameOfTheDragon]

Nope, I can't make it happen. Is there any possibility of getting the customer to reproduce it in PuTTY or a dumb terminal emulator, so we can see the raw output from the rotator?

[rpineau]

I'll first try to reproduce it on my test system, and then if I can i'll give you a full terminal output. but : if (phase == Idle || phase == AtHome) If we start at home and move using the rocker switch then stop. Will the phase variable be properly updated to not be AtHome ?

…

On Sat 7 Dec , at 12:07, Tim Long ***@***.***> wrote: Nope, I can't make it happen. Is there any possibility of getting the customer to reproduce it in PuTTY or a dumb terminal emulator, so we can see the raw output from the rotator? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#25?email_source=notifications\u0026email_token=AAHEDIP5BIZPLTUYUPVR7FLQXP7B3A5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGOMTQ#issuecomment-562882126", "url": "#25?email_source=notifications\u0026email_token=AAHEDIP5BIZPLTUYUPVR7FLQXP7B3A5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGOMTQ#issuecomment-562882126", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

-- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ |

[NameOfTheDragon]

I believe it will be set to Idle the next time there is an onMotorStopped event...

/*
 * Handles the onMotorStopped event. Action depends on the homing phase.
 */
void HomeSensor::onMotorStopped() const
	{
	std::cout << "Hstop " << phase << std::endl;
	switch (phase)
		{
		case Reversing:
			setPhase(AtHome);
			break;
		case Stopping:
			setPhase(Reversing);
			const auto target = commandProcessor.targetStepPosition(homeSettings->position);
			motor->moveToPosition(target);
			break;
		default:
			setPhase(Idle);
			return;
		}
	}

Even if that were not the case, it is explicitly allowed to start another homing operation while already at home, so that would still work.

[rpineau]

Here you go : From power of and dome is At Home. - Connect - Issue a @ghr, it goes all the way around and land home. - use the switch to got couter clockwize - issue a SRR and get a response saying the dome is at home : At this port the AtHome flag is wrong @ghr Phase 1 :GHR# P5111 P5190 P5332 P5536 P5803 P6133 P6505 P6880 XB->Online P7254 P7629 P8004 P8380 P8755 P9129 P9503 P9878 P10253 P10628 P11004 P11378 P11753 P12127 P155 P530 P904 P1281 P1655 P2029 :BV656# P2404 P2779 P3153 P3528 P3904 P4279 P4653 P5028 Phase 2 P5186 P5492 P5736 P5918 XB->Online P6037 P6093 STOP Hstop 2 Phase 3 P6075 P5990 P5843 P5634 P5385 P5188 P5055 P4984 STOP Hstop 3 Phase 4 :SER,4973,1,12347,4973,30# XB->Online @srr :SER,4973,1,12347,4973,30# :left# P4934 P4832 P4731 STOP Hstop 4 :SER,4692,1,12347,4973,30# XB->Online @srr <=== I used the rocker switch to move the dome here before sending the @srr :SER,4692,1,12347,4973,30# <=== It reports that it still at the home position .. it is not XB->Online :BV825# XB->Online XB->Online XB->Online XB->Online :BV825# XB->Online XB->Online XB->Online :BV825# XB->Online Another move using the rocker switch : :left# P4653 :BV825# P4551 P4450 STOP Hstop 4 :SER,4411,1,12347,4973,30# XB->Online @srr :SER,4411,1,12347,4973,30# The AtHome flag is wrong

…

On Sat 7 Dec , at 12:42, Tim Long ***@***.***> wrote: I believe it will be set to Idle the next time there is an onMotorStopped event... /* * Handles the onMotorStopped event. Action depends on the homing phase. */ void HomeSensor::onMotorStopped() const { std::cout << "Hstop " << phase << std::endl; switch (phase) { case Reversing: setPhase (AtHome); break ; case Stopping: setPhase (Reversing); const auto target = commandProcessor.targetStepPosition(homeSettings->position ); motor-> moveToPosition (target); break ; default : setPhase (Idle); return ; } } — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#25?email_source=notifications\u0026email_token=AAHEDIM4IGVTIXRKPYORKITQXQDELA5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGO7QA#issuecomment-562884544", "url": "#25?email_source=notifications\u0026email_token=AAHEDIM4IGVTIXRKPYORKITQXQDELA5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGO7QA#issuecomment-562884544", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

-- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ |

[NameOfTheDragon]

Ah yes. Thanks for doing that @rpineau , that's really helpful. I will have another go at reproducing it here.

[NameOfTheDragon]

OK, yes I can reproduce it now. It's pretty odd because the output doesn't seem to match what the code says should happen.

P47885
P47686
P47565
STOP
Hstop 4
:SER,47522,1,55080,0,50#
XB->Online

With this output, we can see STOP (motor stopped event) and then HStop 4. This is produced in the home sensor onMotorStopped event handler. The 4 is "phase 4" which is AtHome (this is expected at thsi point). However, a few lines later the switch statement should set the phase to Idle (since it is known to be AtHome and not Reversing or Stopping but it looks like that's not happening:

/*
 * Handles the onMotorStopped event. Action depends on the homing phase.
 */
void HomeSensor::onMotorStopped() const
	{
	std::cout << "Hstop " << phase << std::endl;
	switch (phase)
		{
		case Reversing:
			setPhase(AtHome);
			break;
		case Stopping:
			setPhase(Reversing);
			const auto target = commandProcessor.targetStepPosition(homeSettings->position);
			motor->moveToPosition(target);
			break;
		default:
			setPhase(Idle);
			return;
		}

Is there some subtlety of C++ that I'm missing that could cause that default case not to execute?

[rpineau]

If this is based on the homing phase (Action depends on the homing phase. in your comment), then what happen if we're not homing. We were home, then move counter clockwise from home to another position. Then ask for the state (of have the code reports it after Hstop) with SRR, and at this point we know it;'s not home as we just moved it away from home and yet it reports AtHome (1) in the SER status report. When the dome moves, either via a GAR, GSR or manually using the rocker switch, the state of the AtHome flag need to change accordingly. And what happens if I'm somewhere else and manually move the dome using the rocker switch to the home position. Will sending a SRR reports not at Home ? Remember , we're not homing at this point, just moving left or right from the home position. So I'm not sure the issue is the the HomeSensor::onMotorStopped() code, but somewhere else where the AtHome flag should be cleared if the dome has moved and re-asserted if we've moved manually or via GAR. GSR to the azimuth that is the home position. Well sure enough the flag is not set : @hrr :HRR4973# <=== home position @gsr,4973 Phase 0 :left# :GSR# P4981 STOP Hstop 0 :SER,4973,0,12347,4973,30# <==We're home but the flag is not set @srr :SER,4973,0,12347,4973,30# <==We're home but the flag is not set XB->Online @hrr :HRR4973# <== home position XB->Online @prr :PRR4973# <== We're home but the flag is not set So the AtHome flag is not being set properly unless you issue a @ghr, in all other cases it is not updated (either still say AtHome when not at home or not say AtHome when AtHome). So the SRR command can't be used to asses the state of the home position.. this is an issue as I sue this constantly in my code the check for wether or not the dome is at home before sending the @ghr command. Rodolpje

…

On Sat 7 Dec , at 13:13, Tim Long ***@***.***> wrote: OK, yes I can reproduce it now. It's pretty odd because the output doesn't seem to match what the code says should happen. P47885 P47686 P47565 STOP Hstop 4 :SER,47522,1,55080,0,50# XB->Online With this output, we can see STOP (motor stopped event) and then HStop 4. This is produced in the home sensor onMotorStopped event handler. The 4 is "phase 4" which is AtHome (this is expected at thsi point). However, a few lines later the switch statement should set the phase to Idle (since it is known to be AtHome and not Reversing or Stopping but it looks like that's not happening: /* * Handles the onMotorStopped event. Action depends on the homing phase. */ void HomeSensor::onMotorStopped() const { std::cout << "Hstop " << phase << std::endl; switch (phase) { case Reversing: setPhase (AtHome); break ; case Stopping: setPhase (Reversing); const auto target = commandProcessor.targetStepPosition(homeSettings->position ); motor-> moveToPosition (target); break ; default : setPhase (Idle); return ; } Is there some subtlety of C++ that I'm missing that could cause that default case not to execute? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#25?email_source=notifications\u0026email_token=AAHEDIJXRHSJ4EO2P324YNLQXQGWDA5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGPUTY#issuecomment-562887247", "url": "#25?email_source=notifications\u0026email_token=AAHEDIJXRHSJ4EO2P324YNLQXQGWDA5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGPUTY#issuecomment-562887247", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

-- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ |

[NameOfTheDragon]

If this is based on the homing phase (Action depends on the homing phase. in your comment), then what happen if we're not homing.

By design, the state should be AtHome at the end of a FindHome operation and Idle when no homing operation is in progress (it is actually cleared to Idle each time the motor stops, except if the previous state was Reversing). Therefore, it follows that (by design) AtHome will be true at the end of a successful homing operation and false at all other times.

However it looks like there may be a compiler bug that's causing it to generate incorrect code for switch statements. I had something similar elsewhere in the code and I had to re-order my case statements to get it to work. I've re-written it using if statements and its working now. I'll send you a hotfix to test shortly.

Aside: I wouldn't recommend relying on the AtHome flag for anything other than display purposes, because Find Home is an operation, not a position. The AtHome flag has no meaning outside of a Find Home operation and it should never be true except at the end of a successful Find Home operation. There is also no defined "home position" (from the firmware's point of view), there is only the azimuth of the home sensor, which is not quite the same thing, conceptually. The definition is in the FAQ under https://github.com/nexdome/ASCOM/wiki/Home,-Park-and-Home-Sensor-Magnet-Positioning#home-sensor-azimuth.

[NameOfTheDragon]

@rpineau could you give this a go please?
Rotator-3.2.1-Beta.1.zip

[rpineau]

You’re basing your approach on the fact that the application will use an event based system. This is not necessarily the case.. and is certainly is not the case with TheSkyX Pro. It pulls on regular basis, calling methods in the plugin, to get the state of things. So in a sense it’s based on pulling and states. If I can’t assert the state of the dome this make things a lot harder. The AtHome not being a position is one of these problem. Before sending a @ghr (got home) I want to check if I’l already home. Same for the shutter. I want to check it it's closed before sending a close command that would be of no use. That’s the whole point of having a Request Status report command .. to get a proper status on position, AtHome flag and other things. So I strongly disagree with your approach regarding the AtHome flag, it is a state and should be properly reported in all case when requesting a status report. And even if it’s only set at the end of a got home, then you can’t check if you’re home on connect therefore avoid a whole go around to make sure the position reported on connect is correct. So once more, I have to change my code due to some inadequacy of the firmware and some conception that seem to only be logical to you and nobody else.

…

On 07 Dec 2019, at 16:53, Tim Long ***@***.***> wrote: If this is based on the homing phase (Action depends on the homing phase. in your comment), then what happen if we're not homing. By design, the state should be AtHome at the end of a FindHome operation and Idle when no homing operation is in progress (it is actually cleared to Idle each time the motor stops, except if the previous state was Reversing). Therefore, it follows that (by design) AtHome will be true at the end of a successful homing operation and false at all other times. However it looks like there may be a compiler bug that's causing it to generate incorrect code for switch statements. I had something similar elsewhere in the code and I had to re-order my case statements to get it to work. I've re-written it using if statements and its working now. I'll send you a hotfix to test shortly. Aside: I wouldn't recommend relying on the AtHome flag for anything other than display purposes, because Find Home is an operation, not a position. The AtHome flag has no meaning outside of a Find Home operation and it should never be true except at the end of a successful Find Home operation. There is also no defined "home position" (from the firmware's point of view), there is only the azimuth of the home sensor, which is not quite the same thing, conceptually. The definition is in the FAQ under https://github.com/nexdome/ASCOM/wiki/Home,-Park-and-Home-Sensor-Magnet-Positioning#home-sensor-azimuth. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#25?email_source=notifications\u0026email_token=AAHEDIKSKAORJ4CEJAMD3J3QXRAP3A5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGTBQA#issuecomment-562901184", "url": "#25?email_source=notifications\u0026email_token=AAHEDIKSKAORJ4CEJAMD3J3QXRAP3A5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGTBQA#issuecomment-562901184", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

-- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ |

[NameOfTheDragon]

Rodolphe, I acknowledge your disagreement, but as the design currently stands, `AtHome` will only be true in response to a successful `Find Home` request. “Find Home” is an operation that detects the position of the home sensor and resynchronizes the step count internally. This is designed to be as repeatable and precise as possible. I am not convinced that providing the state of a reed switch to the application confers any useful information, since it would provide a `true` indication over a wide range of step positions, most of which would not be the actual home position. That is almost certain to lead to support issues. I’m sorry if this is inconvenient for you but it is what it is at this point. Since the rotator positioning is absolute, the concept of being “at home” is equivalent to being at a known step position. You can synthesize that state in your driver with a trivial comparison with the configured home step position. I might be persuadable if you can show a use-case where knowing the state of the sensor is more useful than knowing the current step position. The other consideration is that there would then need to be an additional way to indicate a failed Find Home operation. Currently that is indicated by `AtHome` being false when the homing operation finishes. Best regards, Tim Long From: Rodolphe Pineau <[email protected]> Sent: 08 December 2019 01:23 To: nexdome/Firmware <[email protected]> Cc: Tim Long <[email protected]>; Assign <[email protected]> Subject: Re: [nexdome/Firmware] When using manual control the home status is not updated (#25) You’re basing your approach on the fact that the application will use an event based system. This is not necessarily the case.. and is certainly is not the case with TheSkyX Pro. It pulls on regular basis, calling methods in the plugin, to get the state of things. So in a sense it’s based on pulling and states. If I can’t assert the state of the dome this make things a lot harder. The AtHome not being a position is one of these problem. Before sending a @ghr (got home) I want ot check if I’l already home That’s the whole point of having a Request Status report command .. to get a proper status on position, AtHome flag and other things. So I strongly disagree with your approach regarding the AtHome flag, it is a state and should be properly reported in all case when requesting a status report. And even if it’s only set at the end of a got home, then you can’t check if you’re home on connect therefore avoid a whole go around to make sure the position reported on connect is correct. So once more, I have to change my code due to some inadequacy of the firmware and some conception that seem to only be logical to you and nobody else.

…

On 07 Dec 2019, at 16:53, Tim Long ***@***.******@***.***>> wrote: If this is based on the homing phase (Action depends on the homing phase. in your comment), then what happen if we're not homing. By design, the state should be AtHome at the end of a FindHome operation and Idle when no homing operation is in progress (it is actually cleared to Idle each time the motor stops, except if the previous state was Reversing). Therefore, it follows that (by design) AtHome will be true at the end of a successful homing operation and false at all other times. However it looks like there may be a compiler bug that's causing it to generate incorrect code for switch statements. I had something similar elsewhere in the code and I had to re-order my case statements to get it to work. I've re-written it using if statements and its working now. I'll send you a hotfix to test shortly. Aside: I wouldn't recommend relying on the AtHome flag for anything other than display purposes, because Find Home is an operation, not a position. The AtHome flag has no meaning outside of a Find Home operation and it should never be true except at the end of a successful Find Home operation. There is also no defined "home position" (from the firmware's point of view), there is only the azimuth of the home sensor, which is not quite the same thing, conceptually. The definition is in the FAQ under https://github.com/nexdome/ASCOM/wiki/Home,-Park-and-Home-Sensor-Magnet-Positioning#home-sensor-azimuth. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#25?email_source=notifications\u0026email_token=AAHEDIKSKAORJ4CEJAMD3J3QXRAP3A5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGTBQA#issuecomment-562901184", "url": "#25?email_source=notifications\u0026email_token=AAHEDIKSKAORJ4CEJAMD3J3QXRAP3A5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGTBQA#issuecomment-562901184", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

-- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ | — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#25?email_source=notifications&email_token=AAJVWCUJLTYX5YMWKICZZ7DQXRD6TA5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGTOXA#issuecomment-562902876>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJVWCWMEG46BBCWAPIEMF3QXRD6TANCNFSM4JXQ5H7A>.

[rpineau]

Looks like this works. I also added some code in my plugin to also check for the azimuth and compare with the stored home position as a double check.

…

On 07 Dec 2019, at 17:20, Tim Long ***@***.***> wrote: @rpineau could you give this a go please? Rotator-3.2.1-Beta.1.zip — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#25?email_source=notifications\u0026email_token=AAHEDIPXQKJE2ZKXTLB54RDQXRDVFA5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGTNTQ#issuecomment-562902734", "url": "#25?email_source=notifications\u0026email_token=AAHEDIPXQKJE2ZKXTLB54RDQXRDVFA5CNFSM4JXQ5H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGTNTQ#issuecomment-562902734", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

-- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ |

[NameOfTheDragon]

Fixed for firmware release 3.3.0, later today.