Comments (10)
Closing issue as the resolution was identified as external (ASCOM configuration)
from firmware.
Tim, can you help me understand the resolution? What does "ASCOM configuration" mean in this case? Does the firmware actually support this, and would a direct driver (not the provided ASCOM driver) be able to do this?
from firmware.
My comment might have been a bit unclear, I actually thought you were asking for something slightly different. OK, let's try again.
The firmware as designed expects to complete the operation in progress before allowing a new one. Therefore it cannot change the destination of a 'slew in progress'. You can argue that it should behave differently but that's how its designed. You either have to get the correct destination to start with, or cancel the slew and start a new one. That's unlikely to change because changing the slew destination can upset things like acceleration and stopping distances.
The firmware is at the limit of available code space so it might not be possible to charge things now, however if you talk to Babak and he's willing to fund the work, then I'd be prepared to re-examine this to see what can be done.
from firmware.
Re-opened pending further discussion.
from firmware.
Thanks for clarifying. Perhaps I can take a look sometime as well, if it matters enough to NINA usability.
from firmware.
@ghilios I've just been working on the firmware and I did some tests on this.
It does seem to be possible to set a new destination while the dome is in motion and it works up to a point, even decelerating and reversing if necessary, but the issue seems to be with stopping. It does eventually stop at the right position, but you usually end up going around twice, which is probably not what you want.
I think this is because of how the step generator keeps track of step position. At the lowest level steps are mapped onto a continuous number line, so you are at A and you want to go to B, you need to move X = B - A steps. At the next level up that's a problem because the dome is circular and its position wraps from 360 degrees (or about 55000 steps) back to 0. The step generator has no way of "wrapping" its step position, so to get from say step position 55000 to step position 10, the step generator is commanded to move to position 55010. The step position is constrained by the limits of an integer in memory and needs to be kept within this range, so after motion stops, the step position is "normalized" back to a small positive integer. Because this only happens after motion has stopped, the calculations seem to go a bit wrong if the target step position is changed on the fly.
The step generator could have been done differently but its supposed to be general purpose and one of the primary design goals was to keep step generation as simple as possible, so it can be done in an interrupt service routine. This is how I get my high step rate with consistent square wave output. So step generation is limited to incrementing or decrementing the position and there's no provision for 'wrapping'.
It might be possible to change this behavior, but code space comes into play. Currently, there is about 4% free on the rotator so it might be do-able. If you would like to have a go and submit a pull request then I'm totally open to that, but for me to work on it I need to receive instructions from NexDome, so it is they who you have to persuade. Perhaps @nexdome would care to comment?
If you are using the ASCOM driver then changes will be needed there too, because the state machine currently only allows a slew command when the dome is stationary. I think that would be a reasonable straightforward change though. The goal here is to arbitrate between conflicting commands from multiple clients. I chose the "first command wins" approach, I never anticipated a single client conflicting with itself ;-)
from firmware.
I appreciate all of this context, and I do understand that you probably can't spend too much more time on it without Babak asking you to. I'll experiment with this a bit and see if I can make some headway.
from firmware.
@ghilios I've just tried this out again using the 4.0.0 beta firmware and it seems to be working now. It looks like the reason it didn't work before might have been related to the "never ending slew" bug. I haven't tested it extensively, but the firmware does seem to handle slew pre-emption using both @GAR
and @GSR
. You might want to experiment with it.
from firmware.
Woah this sounds like a game changer! I've been bogged down at work, and I expect to have some time to test this in the next few days. Thanks!
from firmware.
Closing for now so I can release 4.0.0 with a clean slate. I am going to assume this is working unless you tell me otherwise. You are welcome to re-open if you need to.
from firmware.
Related Issues (20)
- Telescope aperture vignetting caused by 1 degree dome azimuth command resolution HOT 4
- Shutter close sensor does not operate correctly if triggered multiple times HOT 1
- slipping sprocket won't close shutter HOT 5
- When using manual control the home status is not updated HOT 16
- what is current version (3.2.1?) and is there a .hex for it HOT 2
- Auto-close shutter on low battery volts HOT 1
- Incorrect values returned for `@RRS` HOT 2
- Shutter status after manual activation HOT 4
- ArduinoSTL library not compatible with AVR boards v1.8.3 HOT 2
- Dead Zone default is too high HOT 5
- Rotator loses pointing accuracy after many small nudges HOT 2
- Manual Rotator button no longer works with 4.0 HOT 9
- how to update to 4.0.1 firmware? HOT 2
- ASCOM Driver should warn the user if the firmware major version is higher than expected HOT 2
- close ( or stop) should immediately stop if the shutter is trying to open HOT 1
- Does the shutter firmware crash after some time? HOT 3
- Xbee S2C HOT 1
- ArduinoSTL library not compatible with AVR boards v1.8.3
- Req way to force close into the negative on the percent open HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from firmware.