Hi Frederick,

Thanks for your response. The box and the pencil are grayed out.

BR

Marcel

I can confirm this issue on MacOS. It's not even optical trains per se, but it goes beyond that. I'm trying to build a dev environment on MacOS but it's been unsuccessful so far, hopefully Robert can help since he's the expert on this matter.

I'm curious to learn about the resolution to this. I'm running KStars/EKOS 3.6.3 Stable on a Mac Studio running Ventura 13.2. I don't connect directly to my mount from the Mac but rather have an RPi running the StellarMate OS and use it as an INDI server. I communicate with the RPi over my local network. I am not having the problem with the grayed out Optical Trains selections. Is this a difference between connecting directly to the Mac vs using an RPi remotely?

Any news on this, Jasem?

I don't think I saw this when you posted it a month ago, but Jasem did contact me the other day, sorry I haven't had a chance to look into it because I have been really busy. So when Imaging Trains first came out as a feature and I built it for the first time, I had an issue where the camera was not selected, it was grayed out and I had to make a couple of trains, switch from Primary to secondary on every module, and then come back to the primary on each module. After I did that, everything worked as expected. I believe that Jasem or someone else did fix this initial bug that I had. But for me on my MacOS system, I haven't had any issues with it since then. That being said, this does not sound like the same issue because you are saying the editor button is grayed out, right? So you can't set up a train to begin with?

Ok I just ran an experiment. On my Mac, I renamed my kstarsrc file (~/Library/Preferences/kstarsrc) and my kstars data directory (~/Library/Application Support/kstars) so that I was then starting with pretty much a fresh setup. I went to Ekos and ran the Simulators profile (which now is the only one of course since all my others were in the other file.). So then when it started up, I saw the INDI Control window and immediately up came the Trains Editor. I didn't do anything, I simply exited that window and took a look at the various modules in Ekos. They all said "Primary" and I was able to click the edit button to add another train, which I then did, and the drop down menu worked to show both trains. So I don't think I have replicated your bug. Can you please show me how to get it to break so I can try to investigate it? One idea might be for you to try the same experiment, maybe there is something corrupted in your preferences file or your data directory? Note that if you do try the experiment, you can always return your system to its original state by deleting the newly created kstarsrc file and data directory and changing the names of the saved backups back to their original names.

This bug manifests when you try to connect to a remote INDI server (e.g. on Rasbperry PI). It's actually not related to optical trains, but KStars does not receive proper notifications that the remote devices were created. So the chain reaction leads to optical trains not showing up, but the problem is that ISD::ConcreteDevice is not emitting the ready() signal for some reason. I was suspecting a timing or race issue, but I couldn't investigate further since I couldn't build KStars on my M1 machine

So why would I not see this bug? Because I already have my devices and profiles all set up both on my system and my PI already?

I'm not sure. Did you try to create a new profile? Are you using remote webmanager to start the profile..etc?

I don't have access to any of my Pis this weekend since I am on a vacation. But maybe I could do a remote local indiserver, would that have the same effect?

Thanks everybpdy for picking this up. I observed some additional unexpected behaviour today:

I have a profile with an Atik 383L CCD camera and an Atik EFW filter wheel.

When I start this profile I see all the equipment with the exception of the filter wheel.
The FW does not show up in the indi driver tabs and cannot be used.
In this configuration the train dropdown and edit buttons in the camera tab are greyed out.

When I edit the profile and remove the filter wheel, the train drop down and edit buttons are active.
However, in this case, I still cannot do exposures, the camera goes into "capturing" mode and hangs there.

When I add back the filter wheel to the profile, the boxes are greyed out again.

Ok so Jasem and I looked into this for several hours yesterday. The reason I don't observe the bug is because my profile doesn't use the port selector, a newer feature, but all new profiles use it by default. In your case, the profile does not fully start up because it was expecting that the port selector would show up, then you would "connect all" and then it would finish connecting. But apparently what was happening was that the port selector window was not showing up at all, so you couldn't finish connecting. I am not 100% sure why it doesn't show up, but I tried copying in some code from the patch I have been working on for the window-behind other windows bug, and it showed up correctly. So Jasem copied the code that had worked and pushed that line through. He also applied my QML rendering bug fix this morning as well. So I am rebuilding a new DMG with both fixes in it. It should be ready soon.