Gday! I’m strarting to get the hang of writing DragScript, the atomic features are well thought out.
One thing I’d like to see is the ability to check if my mount is homed and if so, to skip homing during a startup,sequence.
Now that I’m reading this I’m nit sure if it’s an equipment issues or a DragScript question. It’s a bit of both I guess as the mount and it’s API would need to support it for the question to even make sense.
Thoughts?
Hello Paul,
Not sure if you know this but in Telescope tab / Bisque TCS / initialization / Home after connect is where you allow your paramount to home after you connect your equipment in Voyager.
My dragscript at the connect block will home my mount.
Hope this helps.
Joe
Hi,
I am taking a more pragmatic approach with my MX+. In Dragscript, at the beginning of the sequence I home the mount, then point the mount close to the zenith and do a blind solve. It takes less than 3 min and it works night after night.
One nice thing about the homing command is that it will put the mount in a known state and ready to operate. For instance if the mount has been homed but is parked you need to unparked first before slewing it. If you simply home the mount at the begining of the sequence you know that the mount is ready and no extra checks are needed. Another nice thing about the homing command is that it will work in any state of the mount, parked, tracking etc, so you don’t need to put the mount in any state before homing it.
Cheers,
José
Thanks! I did but had turned it off and forgotten about it.
I think because during testing with other platforms, I grew tired of the mount homing every time I had to connect/disconnect during testing - not a problem in and of itself, but then the dome would slew and it all got rather tiresome waiting 2 minutes while the whole thing slewed around!
But it’s worth revisiting to see if it addresses the challenge I have during script testing/debugging.
“Ishomed” is a concept not readable by Voyager. So you will not found in DragScript.
Thanks for the idea. Makes sense.
I’m trying to minimise the amount of homing the mount does during testing for the reasons outlined above - lots of waiting around during testing and debugging (my DragScript bugs, not Voyagers) - hence I would prefer to know if it’s homed already.
It’s gotten to the point where I removed the homing command because it was driving me crazy, and then forgot to switch it back on… 
In my old automation world, I’d simply issue a check to see if it was homed and if it was, skip to the next part of my script. A bit like the “Is Open” function call within DragScript (which I do NOT recommend you rely on, at least with the Nexdome, as it can get confused if the shutter partially opens - better to issue the Open Shutter command anyway - which is then also painfully slow when testing)
ideally I would use the DragScript debugger and avoid the pitfalls of real-world testing altogether, but the debugger and I are still learning to get along with each other
Thanks LO - there is an API call, at least for Paramounts - I might just create a hack and call a Python script to check, easy enough to do as it looks like I’m the only one.
Paul… Voyager is a system integrator … Home block work for all system that have it and not all have to check if is homed … also this check is really unsafe.
So you will not found in Voyager !
Understood, thanks Leonardo
Paul
I have a series of ‘flags’ at the start of my Dragscript to turn on and off certain elements and one of mine is Home Mount = y/n. You can then have a block called Home Mount and make that conditional on the flag.
Chris
Thanks Chris, good to know I’m not the only one!
I was contemplating a similar approach. I’m almost at the point where I feel the need to write a GUI to manage flags in my DragScripts outside of changing the script itself each time. (at least until the “Advanced” edition arrives)
At the moment I’ve got variables/flags for "collect dawn flats, collect dusk flats, “is-testing” (essentially a way of enabling me to comment out a line/block of DragScript code while testing, I do wish there was a way to do that more easily) and it looks like a “is-homed” might also be a good idea.
My logic being;
1). startup and home everything once during a night/day/session
2). don’t home again while “is-homed” is true UNLESS
3). a watchdog/retry fails in which case it might be worth homing everything again just in case the dome/mount/focuser/rotators etc have gotten themselves into a mis-callibrated state.
The latter (3) has never happened with my Paramount, but my EQ8-R has ben known to develop “interesting” ideas about where it is pointing - same with the Nexdome, generally okay, but has once or twice skipped a few teeth on the rotator belt during a night and I managed to get some nice dome flats :-), focuser is very reliable, but it also supports a homing function (effectively a way of making a “relative” Crayford focusers as close to absolute as you can get).
Again, this looks like something I’ll have to maintain my own workarounds for, it’s not that important in the grand scheme of things.
For my way of working it would be nice if DragScript could allow for extensible libraries (like Python) so that the set of available functions could be extended as required (and shared between users with similar needs - like us) - but I assume it’s a tokenised runtime language (a bit like BASIC from what I can see) and I suspect this would be really hard to do without breaking what makes DragScript so easy/quick (and sometimes painfully slow) to work with (eg: manning the namespace for variables, etc)
DragScript isn’t a language. Is just a drag and drop of little action block with some logic.
You have external script interaction if you need programming language or scripting.
Fair point! But I will say that one of my DragScripts gave me a “syntax error” message the other day, I think that technically only a language can have a syntax error (I am just kidding by the way, but I did get a syntax error 
My apologies for joking. It is a good reminder.
DragScript is such a powerful (and easy) concept that the line between “language” and “state-machine” gets blurry. The system is so powerful with things like IF, GOTO and REPEAT statements it is easy to forget and start to expect similar things that you see in a more traditional 2GL/3GL.
That is a compliment to the designer!
Voyager is just a little application for AP automation. We are sure there are better solution for all but we try to do our best.
Sometime think different is something to be proud.
Paul
Over the years I have used pretty much all the automation options out there, including some eye-wateringly expensive ones. Voyager is the only one I have stuck with and it has never let me down. Complexity does not always mean reliability. Voyager and SkyX together do everything I need.
I maintain a baseline dragscript setup with simulators as a development version. I keep a copy of that as a master and then copy it again as my nightly script. Only the latter is populated with real target sequences. More often than not I will go outside if its clear and setup manually so will home and park the mount and the script will take it from there. Sometimes though I will want to start from a certain time or wait until astro darkness so have flags for either option. I then have flags for whether to run each of six sequence blocks. Its pretty simple and could do with a bit of tweaking but it has worked faultlessly.
Chris
Thanks for your note Chris - I woudl love to learn more about how you do things, there’s a “Voyager way of thinking” that takes some time to get your head around and examples like yours help me rethink old problems in a different way - this forum helps a lot in helping to encourage me.
I suspect the Advanced version will make most of my hacks/workarounds redundant - I can’t wait.
It also the only platform I’ve seen that integrates so seamlessly with TheSkyX (which I have to use because of my Paramount - don’t get me started!), which I why I made the leap (that and Diego Colonello in my ear, all day every day “Voyager!” 
With DragScript, Arrays, Viking and (soon) Rental, there’s really no alternative that meets the reliability and LIVE support you can get from Voyager, so it’s a no-brainer winner. I’m convinced that Voyager will eventually displace everything but the simplest use-cases for astro imaging data collection.
I’m trying very hard to change my ways to use it - there’s a certain iconoclastic mindset that requires you to think “the Voyager way” that rewards commitment if you’re prepared for it.
On the plus side, it’s super efficient at some things (SKY FLATS - YAY! SUSPEND/RESUME and weather condition management - yay!). Sometimes, it feels like it takes twice as much effort to do something that was simpler in my old automation platform (scheduling an RA ascent-time optimised & constrained run of three galaxies with an instantly calculated estimate of the start and end time of each - right now requires more gymnastics than was used to having to do in Ekos) - but the pro’s outweigh the cons.
Again, simplified scheduling seems to be addressed with the Advanced product - I am sure it will be awesome.
DragScript (a subtopic of the original thread) is somewhere in-between for me - it’s unique and brilliantly addictive in its ability to enable me to create bulletproof, predictable outcomes to a set of complex conditions - just amazing. But also frustrating, I’ve managed to “logic” myself into doing the right thing at the wrong time on more than a few occasions It reminds me of doing home automation with LUA! (ask me about the time I programmed ALL the bedroom lights in my house to go ON in the middle of the night instead of off, the family was not impressed!)
While we’re sharing, like you I’ve played with a few automation and integration setups in my short time (one year) in the hobby so far - Ekos/INDI, TheSkyX, MaximDL, PHD2, etc - not quite made it to the level of $$$ insanity that is ACP (nor would I ever!).
I agree that of all of them, Voyager is the one that’s most feature complete in terms of solving the gnarly problem of integrating the mess of astro software and hardware widgets into a coherent automated whole.
I believe that many of the difficulties you encounter are due to the fact that you want to use a program as if it were another previous one. It takes a few blocks for example to create a scheduler for shooting months, if instead of calculating the time you use the HA maybe then you also realize that you can let the script go for weeks and months as many do.
As always I try to do my best but throwing away 15 years of experience in astrophotography at a certain level on things that do not bring results to please everyone is not the philosophy of this program, otherwise we would all have the same programs, our photos would be all the same etc.
As I have told others, if you feel comfortable with other programs there is no harm in wanting to go back. Ekos is a bit like telling me that turning in the shuttle cabin is easier than inside any other car … the problem is all you have to go through to get there in orbit. The bottom line is that there is always greener grass from the neighbor … it’s figuring out if green grass is the thing you want or just the idea of green grass you don’t have that makes you dissatisfied.
Maintaining one’s identity can be an added value as a reason for strong hatred and adversity (lately I think the second hypothesis).
Sorry for the philosophical digression, however, in a language that I don’t speak well at all.
It takes courage to push through a different path, being an innovator is not for people who like an easy life and always good news - you should be extremely proud of what you’ve created Leo.
Comparisons and seeing patterns & differences with other ways of working is one of the ways the human bring is wired - we share ideas about the new by comparing it with the past, it’s how we measure progress (and sometimes not progress depending on how you feel about Brexit
The philosophy behind what and why you do what you do is probably more important than any other aspect of your platform, non need to apologise, it’s helpful to understand your strategy.
I’m looking forward to seeing how Voyager grows into its future.