Dev logs of Rebar Addon for FreeCAD - GSoC project

[amrit3701]

I have put my all development logs of my GSoC project on regular basis here.

Also, you can also check my development logs (https://brlcad.org/wiki/User:Amritpal_singh/GSoC17/logs).

Regards,.

[amrit3701]

As per according to my proposal (), before the first phase evaluation, I will cover the reinforcement of the footing. The shape of rebars which I have covered in this period are straight and C shape. At the end of fist phase evaluation, we have one drop-down list (present in the Arch workbench) in which different rebar shapes (straight and C shape) are present and after selecting the specific shape rebar, a dialog box in the task panel will open. After filling that form, user will click on the 'OK' button and reinforcement is completed.

TODO tasks list form 1 June to 13 June:
1. Writing scripts for straight and C shape rebar.
2. Making UI (dialog box) for the above two rebars so that end user will execute my scripts.

Comments are welcome. If anybody wants to add anything then please tell me.

Regards,

[yorik]

Looks perfect! As soon as you have code, please also share it here, we like to see code

[amrit3701]

Looks perfect! As soon as you have code, please also share it here, we like to see code

Here is code: https://github.com/amrit3701/FreeCAD-Reinforcement

On studying again it deeply, I have found a couple of shortcomings in my present scripts.
1. I have used some constant in my code like if a user selected rebar along length then the sketch will be drawn on Face1 of the structural element and if a user selected rebar along width then sketch will be drawn on Face6. But due to topological naming problem Face1 always not along the length of the structural element and same for Face6.

2. I have defined things like the origin of the sketcher will locate on the left side for the Face1 and in the centre for Face6 because I unable to find the relationship between the sketcher origin with respect to different faces of the structural element. I explained this problem in more detail in the given below thread:
https://forum.freecadweb.org/viewtopic. ... 20#p170178

Can anybody help me how I can overcome all the above problem?

Regards,

[yorik]

Okay looks good so far. I'm duplicating below the screenshots from the other post so it's easier to discuss here:





About your questions above:

1. I have used some constant in my code like if a user selected rebar along length then the sketch will be drawn on Face1 of the structural element and if a user selected rebar along width then sketch will be drawn on Face6. But due to topological naming problem Face1 always not along the length of the structural element and same for Face6.

I believe the best way is to make the user pick a face himself. As this can be confusing (the user might be in doubt what face needs to be picked), you could add a little svg diagram on top of the dialog to illustrate what he needs to do, a bit in the same style as the diagrams in the Arch structure -> concrete prefab presets. So an easy way would be to (maybe) add such a diagram (how are your drawing skills? ), and a "use selected face" button. When clicking the button, you check if a face is currently selected with Gui.Selection.getSelectionEx().

2. I have defined things like the origin of the sketcher will locate on the left side for the Face1 and in the centre for Face6 because I unable to find the relationship between the sketcher origin with respect to different faces of the structural element.

I don't think the placement origin is really important, but it is doable, once you have a face, you could simply take its CenterOfMass attribute and its normal direction (normalAt()). With these two things, you can get a center point and a rotation (The App.Rotation object has several useful construction methods,one is by giving it a "from" and "to" vectors). Then you set the placement of your sketch from these two things (you must create a new placement, then give that placement to the sketch).

Other comments I have:

3. Bernd should have a look at your dialogs above to see if he thinks it's right. I'm not proficient enough in reinforcing bars to judge, I'm only a simple architect

4. Instead of simple QLineEdit fields, you should use our FreeCAD Gui::InputField, which supports units, expressions,etc. These should normally be in your QDesigner if you compiled the FreeCAD plugin for it. Otherwise, you can also add them from the python code, after you loaded the .ui file:

Code: Select all

ui = FreeCADGui.UiLoader()
myField = ui.createWidget("Gui::InputField")

[amrit3701]

4. Instead of simple QLineEdit fields, you should use our FreeCAD Gui::InputField, which supports units, expressions,etc. These should normally be in your QDesigner if you compiled the FreeCAD plugin for it. Otherwise, you can also add them from the python code, after you loaded the .ui file:

Code: Select all

ui = FreeCADGui.UiLoader()
myField = ui.createWidget("Gui::InputField")

I have fix all the bugs which I have discussed in my previous post and also use FreeCAD widgets to create UI of straight rebar taskpanel.

Here is the source code:
https://github.com/amrit3701/FreeCAD-Re ... htRebar.py
https://github.com/amrit3701/FreeCAD-Re ... htRebar.ui

Comments are welcome.

Regards,

[yorik]

I had a quick test, so far so good! I think you are attacking things the correct way. At the end, we should have a series of these python scripts + ui pairs, each one adressing a certain type of rebar.

A couple of observations specifically on the TaskPanelStraightRebar:

1) Some imports are missing: import FreeCAD, FreeCADGui and import Part. Attention, here there is a catch: FreeCAD and FreeCADGui are lightweight, because they are loaded at FreeCAD start anyway. Part, however is a heavyweight module (it loads good part of the OCC libs). So we try, in FreeCAD, to avoid loading Part at FreeCAD start. The solution is not to import Part at the start of the file (because when your tools will become official FreeCAD tools, these files will probably be loaded at startup), but inside the functions where you need Part. Even if that means there will be multiple "import Part" in a same file, that doesn't harm (python will only load it once anyway)

2) The path to the .ui file can be found automatically (you first need to rename the .ui file with the same name as the .py file, but it's good practice anyway): os.path.splitext(__file__)[0]+".ui" (need to import os too of course)

3) Putting all your "real" code inside a try statement is bad practice. It makes it more difficult to trace the cause of problems. For example, on first run I was able to get the script tell me "Done!", however nothing was done. To me it is better to remove the try statement entirely, and let the script fail when needed, it will be much better to fix its weaknesses as they appear and make it more solid.

4) It is not obvious to the user at all that he/she needs to select a face of a structural element before running the script, and it fails silently without informing the user. You should at least check, when the script starts, if the selection contains what you want. Even better, on your ui, the selected face could appear, and a way to change the selected face should be offered (a simple "use selected face" button maybe). There could be a small image illustrating what face should be picked too, I'll try to make one for you.

5) The radio buttons amout/spacing are both unselected at script startup. I would set one selected as default...

*EDIT* 6) It is not clear in which unit the diameter is expressed

Now I have another, more general idea. That is more for the long-term but it would be good to add at some point, I think:

It would be good that, if the user created a Rebar object with one of your dialogs, it would be possible to edit that Rebar later, with the same dialog. To achieve that, we could do something like this:

1) We add a (hidden) property to the Rebar, for ex "UiModule", which contains the name of the script used to produce the rebar, for ex. "TaskPanelStraightRebar".

2) In all your script, there sould be a same function, for ex. editDialog(rebar). You must make sure that, given the rebar object, that function would be able to fill the dialog with correct values again. You should also change your current script so it is possible to import it without running anything.

3) When double-clicking a Rebar object, if the UiModule property contains something, the corresponding module is imported, and its editDialog() function is ran.

4) You must modify the Accept function, so if an existing rebar was provided, change its properties as needed instead of creating a new one.

How does that sound?

[yorik]

Something like this:

TaskPanelStraightRebar.svg

(5.36 KiB) Downloaded 295 times

[yorik]

I still have problems running your script... even selecting a face, I couldn't make it create a rebar yet. It finishes, says "Done" but there is an empty sketch created, the dialog is not closed, and no rebar object is created.

[amrit3701]

4) It is not obvious to the user at all that he/she needs to select a face of a structural element before running the script, and it fails silently without informing the user. You should at least check, when the script starts, if the selection contains what you want. Even better, on your ui, the selected face could appear, and a way to change the selected face should be offered (a simple "use selected face" button maybe). There could be a small image illustrating what face should be picked too, I'll try to make one for you.

5) The radio buttons amout/spacing are both unselected at script startup. I would set one selected as default...

*EDIT* 6) It is not clear in which unit the diameter is expressed

Okay, I will fix them.

Now I have another, more general idea. That is more for the long-term but it would be good to add at some point, I think:

It would be good that, if the user created a Rebar object with one of your dialogs, it would be possible to edit that Rebar later, with the same dialog. To achieve that, we could do something like this:

1) We add a (hidden) property to the Rebar, for ex "UiModule", which contains the name of the script used to produce the rebar, for ex. "TaskPanelStraightRebar".

2) In all your script, there sould be a same function, for ex. editDialog(rebar). You must make sure that, given the rebar object, that function would be able to fill the dialog with correct values again. You should also change your current script so it is possible to import it without running anything.

3) When double-clicking a Rebar object, if the UiModule property contains something, the corresponding module is imported, and its editDialog() function is ran.

4) You must modify the Accept function, so if an existing rebar was provided, change its properties as needed instead of creating a new one.

How does that sound?

Great sound! Actually, I also have the same idea like if a user wants to re-change the values present in the dialog box then they will double click on the rebar and then a dialog box will re-open in the task panel. I will try to implement this.

Regards,