UC2 Online Configurator

[beniroquai]

Based on the work by the openflexure team and @AlecVercruysse, we want to have an online configurator which allows the creation of ready-to-print .zip-files of UC2 Applications which are always up-to-date.

The script which generates JSON files for each APPLICATION now successfully converts the excel sheet into a useful JSON-file. It's still experimental and can be found here.

@AlecVercruysse I still didn't consider the ability to conditionally choose options. I think therefore I need to get a better idea of what it could be. Do you mean something like camera: A or camera: B and lens: A or lens: B in one Application?

Also, would you mind to see if the structure fits what you would expect in your online configurator?
Anyway, I'll try to have a look at your VUE code and see if I have any chance understanding it ;)

[beniroquai]

@AlecVercruysse I reviewed your code of the UC2 and I thought that it might be easier to eventually load everything from the JSON-files in the Application folders rather than going through all STL subfolders and creating lists this way?

Taking this config.json as an example, I could imagine, that we could try to load the whole per-Application configuration from only this file, rather than each subfolder individually or what would you say? I must admit, that I don't have enough programming skills to do that right now. Maybe you could help me out with this? :)

I think it would be quite handy to have one database file (i.e. excel sheet) which hosts all the configurations. From there we can maintain everything much easier. Even though I think the current excel file is not ideal, I believe it's a good start.

[AlecVercruysse]

@beniroquai, the reason I went for the modular config was so that only one copy of a module config was present for that module. Any change to that module's config would therefore not have to be propagated to all the other copies of that config, for example in the application config you linked.

Having the master database would certainly help, because it could do a lot of the heavy work in terms of propagating the changes in a config, but this requires the excel sheet to be able to handle the complete generation for every single config for it to work well in my opinion, something that as of now would certainly require a lot of changes to the spreadsheet.

If, by "conditionally choose options", you mean the "dynamicExtraParts" field I proposed in #32, I think you have the right idea. For example, some applications use the lens holder cube with lenses of differing focal lengths. It should be specifiable, in the configuration for the app, which focal length lens the module uses, in order to be able to provide a better BOM.

I agree that I think the most important priority is editing this spreadsheet to allow for it to generate better configs, as seen with #32, specifically with fixedFiles and dynamicFiles.

Apologies for not being so responsive, I should have much more time, especially to take another look at the config generation script, once this week ends.

[beniroquai]

Ah, now I think I got it. Well deeply buried in the sheets there is the initial table which refers to the modules with internal links rather than hard coded links. I'll have a look.
The current app config.json files combine the app and module information and have additional part information. Maybe the way to go for now?

I also try adjusting the uc2 selector such that it only relies on the app config.json. I must admit, that I'm lacking way too much knowledge in JavaScript, but I'll manage. Perhaps ;-)

[b286]

It would be great if it can keep the hierachy of Application - Modules - Parts. Also, would be nice to have the option to have the option to generate a module only - without an application that is using it.

[AlecVercruysse]

@b286, I agree that this hierarchy is one of the many great things about the current UC2 standard. To keep this, and the ability to generate standalone modules, present in the configurator, @beniroquai, I believe it would be best to separate out the config files.

[beniroquai]

Thanks @AlecVercruysse for your response. I would "just" update the conversion script to automatically generate the modules from the excel sheet. This could go to the module folders in "Assemblies"

Nevertheless, I would like to let the online configurator simply look up the config.json files scan the printable parts and display them for downloading. This is true for Applications and Modules. So for a given Application it reads only the config.json inside the Application folder, same for the module inside the Assembly-folder. Does this makes sense to you?

This way you can download individual modules/parts and whole assemblies.

Perhaps it would be cool to display additional information such as parts to buy and setup infos - that'S all inside the excel sheet already ;-)

Maybe a bit confusing, hm? Sorry ;-)

[beniroquai]

I have updated the python script which now produces config.json files for applications and modules. I hope that makes sense. I'm definetely not a programmer and everything is very hacky..but it seems to be working. Also I noted - probably what you had in mind all the time - that in rare cases it's possible to have modules inside modules (i.e. basic cube). Hacky workaround is implemented and I hope that'S the only exception.

@AlecVercruysse do you think we could work with this? I'm still trying to modify the javascript stuff, but I think you're on a different level!

@b286 would you mind to have a look at the missing modules inside the CAD which are not yet inside the excel sheet? E.g. the Basler camera module is not inside the sheet. It also won't get called by any application, but we need to generate the json file for that. Thanks! :)

[b286]

Updated. All modules from CAD should be in the excelsheet now (NEW Complete overview).

[AlecVercruysse]

Hi @beniroquai,

The current behavior of the configurator is to lazy-load required configs. So if the user selects an application, it checks to see if the application config.json has already been downloaded, and if not, it will download and parse just that config. The same goes for any modules: for every module "active," the configurator will check if the module's config is loaded, and if not, it will download and parse it.

If I properly understand your requested change, you'd like each application config.json to load the config for all modules it depends on as well? In practice, this would simply reduce the amount of config downloads to one per application, instead of 1+<# "new" modules> per application. I might still be confused however, since it seems like with this configurator you already can download whole assemblies as well as individual modules (once the config files for all modules have been made, of course).

I agree the extra functionality of prices, photos, etc. Would be cool! Unfortunately I do not have much access to my computer these next 2 weeks (until my school restarts) so I can not guarantee that I can make the changes very soon, unfortunately.

[beniroquai]

Hey @AlecVercruysse how is it going? Sorry for late reply. Are there any news? ;)
I'm still very curious (and not really able to program javascript ..)

Cheers

[beniroquai]

Hey @AlecVercruysse how are you? May I ask you to help me out with the configurator in the next days? Maybe we could chat through Zoom briefly such that I can make some alterations in the code on my own? Thanks a lot! :)

[AlecVercruysse]

Hi, apologies, school (remote learning here in the US) has left me very busy with work and not so much free time to contribute to other projects this semester. Certainly I would be able to chat for a zoom call. I've reached out via email to schedule a call.