Python headaches with decimals and Alibre lofting error

[stepalibre]

I understand much much better now. Thank you

 

[stepalibre]

Ok. I'll rewrite this and let's discuss my changes:

When I run it this was the output:

>>>
Input Number of Guide Curves (typ - 10), then press ENTER
10
101
['1224.7348', '1039.3295', '173.5912', '1219.8444', '1041.3338', '172.0690', '1219.7922', '1046.2421', '178.6999', '1216.2133', '1047.7089', '177.5859', '1216.1981', '1049.1405', '179.5199', '1217.8986', '1048.4435', '180.0492', '1217.9008', '1048.2390', '179.7730', '1222.9689', '1046.1618', '181.3505', '1222.9668', '1046.3663', '181.6267', '1224.6673', '1045.6693', '182.1560']
Traceback (most recent call last):
File "<string>", line 448, in <module>
TypeError: expected float, got str
>>>

Is this the same when you run it? Is the loft made by another script?

 

[stepalibre]

It could also be that I have put lists within a list...again

Yes, it's clear now.

You're performing calculations in Alibre, I would not do this in a serious project where performance, stability is needed. It's perfectly acceptable, in prototypes and experiments, but it is significantly more performant and easier to manage when this part is external. IronPython2.7 running inside Alibre Design will never be the most performant, you'll have more headaches.

Using Python or IronPython directly, outside of Alibre might be faster.

I'll pass it though AI and see what comes out.

 

[davex7637]

Yes, I end up with the same results. The last portion to add the loft hasn’t been added, just yet. I was working through each step to verify if it worked.

I do remember you mentioning performing all calculations in other programs, Matlab in my case. But I am unaware of how to bring the final data and produce the splines, points, plames, and sketches iteratively. Loops in python don’t behave similarly to Matlab and with my limited python experience it ends up looking like this. Thank you for looking over it!

 

[stepalibre]

I can't post code here, always hit the text limit, so see link. It's only a clean version that added functions making the code more readable for me. I'll review the original and the clean version together.

python-headaches-with-decimals-and-alibre-lofting-error | Notion

import fpformat Win = Windows() CurrentPart = CurrentPart() txtfile = Win.OpenFileDialog('Select 3D Pojnts in TXT,mm', 'TXT files(*.*)|*.txt*', '.txt') f = open(txtfile, 'r') datareader2 = f.read() f.close() data_into_list =...

donetoolkit.notion.site

performing all calculations in other programs,

It's not required, you can use Alibre Script addon for everything. Any external tool could help you become more efficient, the fewer lines of code in Alibre should add up to something better, faster, more robust, especially with the tools and tech we have today. Excel is a great example.

 

[stepalibre]

Something else to consider.This is IronPython not regular Python, there are IronPython and Python types, and they don't always work well together. Alibre Script API has it's own expectations and quirks to look out for.

 

[stepalibre]

AI may have fixed it. Review it and let me know. If it's not fixed I can look at it.

This was the output before and after output:
>>>
Input Number of Guide Curves (typ - 10), then press ENTER
10
101
['1224.7348', '1039.3295', '173.5912', '1219.8444', '1041.3338', '172.0690', '1219.7922', '1046.2421', '178.6999', '1216.2133', '1047.7089', '177.5859', '1216.1981', '1049.1405', '179.5199', '1217.8986', '1048.4435', '180.0492', '1217.9008', '1048.2390', '179.7730', '1222.9689', '1046.1618', '181.3505', '1222.9668', '1046.3663', '181.6267', '1224.6673', '1045.6693', '182.1560']
Traceback (most recent call last):
File "<string>", line 266, in <module>
>>>
Input Number of Guide Curves (typ - 10), then press ENTER
10
101
[1224.7348, 1039.3295000000001, 173.59119999999999, 1219.8444, 1041.3338000000001, 172.06899999999999, 1219.7922000000001, 1046.2420999999999, 178.69990000000001, 1216.2132999999999, 1047.7089000000001, 177.58590000000001, 1216.1981000000001, 1049.1405, 179.51990000000001, 1217.8986, 1048.4435000000001, 180.04920000000001, 1217.9007999999999, 1048.239, 179.773, 1222.9689000000001, 1046.1618000000001, 181.35050000000001, 1222.9667999999999, 1046.3662999999999, 181.6267, 1224.6673000000001, 1045.6693, 182.15600000000001]
>>>

run1 = Original , run2 = AI Fix








Added code to database:

python-headaches-with-decimals-and-alibre-lofting-error | Notion

import fpformat Win = Windows() CurrentPart = CurrentPart() txtfile = Win.OpenFileDialog('Select 3D Pojnts in TXT,mm', 'TXT files(*.*)|*.txt*', '.txt') f = open(txtfile, 'r') datareader2 = f.read() f.close() data_into_list =...

donetoolkit.notion.site

 

[stepalibre]

Can't add the CAD file, so added it to database page.

I misunderstood where the points were. I thought the points were only in a single 3D sketch from your data. Your script separate them into individual sketches.

 

[davex7637]

View attachment 44380
Can't add the CAD file, so added it to database page.

I misunderstood where the points were. I thought the points were only in a single 3D sketch from your data. Your script separate them into individual sketches.

I seem to keep getting the error. I used the "AI-Clean" code.

 

[stepalibre]

The code block not the file links.

 

[stepalibre]

Regular ChatGPT was able to fix the issue. Most AI models can be used for common Python and IronPython coding problems. AI's need Alibre Script data in order to fix and generate functional code. In this case, since the issue was not related to the Alibre Script API, the AI was able to learn from the script and resolve it. This is not always the case, so it is not safe to assume that AI will be able to resolve every issue even with context.

 

[bolsover]

I also have had issues with resolving coincident points when calculating spline points. When working in mm, I have generally solved by working to 6 decimal places or 1 nanometre resolution. It all comes down to a question of 'what is the maximum distance two points can be separated by before they are considered coincident?' I suspect that if you ever need better than 1 nanometre then some scaling will be needed!

 

[stepalibre]

scaling

I start with scaling and subdivision of lengths and distances. It seems that in 3D CAD API development and generally you need to work at a "workable scale" the tools are design for and refine from there. Most of these issues are caused by the GUI and related systems not necessarily the API or kernel.

 

[stepalibre]

I start with scaling and subdivision of lengths and distances. It seems that in 3D CAD API development and generally you need to work at a "workable scale" the tools are design for and refine from there. Most of these issues are caused by the GUI and related systems not necessarily the API or kernel.

More on this topic: Parameters are passed though the equation/parameter system (no idea what they call it internally) is another place where your calculated values might become truncated or have an reduced precision. This is likely why 6 places in some cases will solve this type of issue is it the max. If the value is more than 6 it might not work. I perform important calculations externally where I can use more than 6 places and control the input and output. When I import the data or set a parameter value I know what the value should be and if I get different numbers I know where to look. 10 decimal places is what I've found to be a good number for both CAD and programming applications.

 

[davex7637]

I decided to count how many decimal places "print" when float is applied. In Alibre V25 (what I'm using), the decimal points round to 13 places. I exported the data to 15 decimals in Matlab, and by default the rounding made the loft work first try. No formatting, no round function...etc.


If I apply this to the AI script you made, I can only imagine how quickly these parts can be generated. Thank you for your help! If all else fails, count how "precise" the program is reading to. I have chatted with support in the past, and I do recall them mentioning a large amount of decimals past 5 or 6 for alibre functions. Also, I know I can manipulate Matlab to far more precision, if necessary.

 

[stepalibre]

manipulate Matlab to far more precision

Exactly!

I exported the data to 15 decimals in Matlab, and by default the rounding made the loft work first try. No formatting, no round function...etc.

Alibre displayed unit precision is 6, equations enforce 6. This then leads to conflicts with code and data of a higher precision.

SolidWorks has 8
FreeCAD has 16

I built these scripts to allow for quick parameter changes, I also wanted a way to check equations easily without limits. The program can use the full value for calculations. Alibre will still stop at 6.

SimpleEE (Simple Equation Editor) 2 | Notion

Made with Notion, the all-in-one connected workspace with publishing capabilities.

adai.donetoolkit.com

SimpleEE (Simple Equation Editor) | Notion

Made with Notion, the all-in-one connected workspace with publishing capabilities.

adai.donetoolkit.com