Fusion API and Scripts
Got a new add-in to share? Need something specialized to be scripted? Ask questions or share what you’ve discovered with the community.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Parameter I/O - Import Error

Message 1 of 15
1222 Views, 14 Replies

Parameter I/O - Import Error


I've been having trouble importing parameter lists using this AddIn.  I get the below error, which doesn't mean much to me.


Steps taken: 

  1. Export parameters from other prior design using this Add-In.  Save as csv.
  2. Open csv with Excel to modify list - clean up unused items, alphabetize (Filter A->Z by name) and otherwise tend to the list.  Save as csv.
  3. Upload csv file with AddIn.

Is Excel doing something to the csv properties of the file, perhaps?  I am being sure to Save As .csv after modifying the list, and the csv. file icon says "csv" on it.


I presume what I'm trying to do is the best way to share parameters between files, or at least introduce a "standard" list of parameters to a new design?  And, to edit this parameters list, in particular to alphabetize so the list is easier to use (70 parameters and counting...).




Parametre I-O Error.JPG



Tags (1)
Message 2 of 15
in reply to: joelCA3M6

Hi Joel,


I was facing a similar error. Though in my case it turned out the error was not caused due to editing of the csv file but due to an inherent problem in the parsing of units. Simply put - while entering the unit INCH I had used the symbol - ". This the same symbol used by parser to encode data. Thus the conflict in the import of data.


Any ways - I would suggest you try replacing you <"> with inches / inch / in in units and exporting again. That should resolve the issue with imports. Then you may edit the CSV file as you require.


Hope this helps.




Message 3 of 15
in reply to: mr2234

You might want to take a look at this post to learn about some common issues when using the add-in.


Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 4 of 15
in reply to: joelCA3M6

Parameters need to be entered in dependency order, for instance if parameter A is B * 2, then parameter B has to be put in the file first.

That can contradict "alphabetical order".


If you enter parameters by hand, the same rule applies, but you can go back and edit an earlier parameter in the list to depend

on a later one.


The add-in ParameterIO is a very naive program and just crashes when it gets out-of-dependency-order parameters. A more

sophisticated program could use the trick above and enter parameters in any order.

Message 5 of 15
in reply to: julian.tilbury

I agree that the program is very simple and should be enhanced.  When the API was introduced several add-ins were written as samples demonstrating various areas of the API.  Their main intent was to demonstrate the use of the API.  They were not written to be full featured or even very robust in their behavior.  This particular add-in gets enough use that we should re-write it and make it better.

Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 6 of 15
in reply to: ekinsb



I've already written my own. One feature is sorting parameters in dependency order.


BTW, the API could do with a function to delete a user parameter. The API can already overwrite

everything and rename the parameter, so it can totally obliterate a parameter. i.e. turn:-


Height mm  20 mm  The height




junk mm 999999999 mm its junk!


So the absence of a delete function doesn't protect from errant code or an insane user.


I have files with logical sets of parameters, and an instruction file that tells my add-in which files

to load into which designs. By changing the instruction file I can remove a set of parameters from

a design. As I can't delete spare parameters I rename them delete_me_1, delete_me_2, ...



I also note that renaming a parameter doesn't chain to its dependents. I haven't decided

if this is good or not. It is probably good since I don't care about leaving the parameter list

in an invalid state in the middle of a transaction. As long as it is valid when I'm finished

everything is ok. However, you can't write an invalid expression, but you can rename to

invalidate a dependent expressions, so this is a logical contradiction. So neither the UI

nor API maintain the integrity of the parameter list.


An external parameter manager could also do with a list of reserved words e.g

cos, sin, in, min, max etc. that it obtains by an API call. That way if Fusion adds

a function a good exernal parameter manager will automatically adapt to the








Message 7 of 15
in reply to: julian.tilbury

I'm not seeing the same things that you're seeing.  The UserParameter object supports the deleteMe method.


I'm also not seeing the renaming issue you described.  I created:


a = 1

b = 2

d = a + b


And then renamed "a" to "George" and the expression for "d" was automatically changed to "George + b".


A reserved name list would be useful.  An alternative you can use now for some cases is the isValidExpression property of the UnitsManager object.  You can do a quick check of an expression to see if it is valid before trying to use it to create a parameter.

Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 8 of 15
in reply to: ekinsb

Thanks. I was reading the Parameter documentation. I missed the UserParameter documentation.


I think I got an inconsistent parameter set during my debugging, but was tracing multiiple bugs

so wasn't paying that much attention, and I have since deleted the test designs. If I find one

again I'll let you know.

Message 9 of 15
in reply to: ekinsb

If a user parameter has a $ in the name then renaming the parameter does

not propagate to parameter expressions which reference the name,


(I'm using $ to have names of the form prefix$suffix where

the prefix refers to a logical set for a component. I could have

use _ instead of $ had I spotted this "feature" earlier

but now my parameter management code accidently

relies on it.)


(Fusion 2.0.3302)

Message 10 of 15
in reply to: julian.tilbury

The behavior with the $ in the name seems to be a general problem with parameters and nothing specific with the API.  I've logged a bug.

Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 11 of 15
in reply to: ekinsb

I have another "bug" for you.


As you know, I've written my own parameter importer/exporter.


It works fine until I (multi) undo after an alteration to the design and

re-import. At that point many parameter values become read-only and

refuse the new imported values.


I have a deadline, so don't have time to produce a 20 line test

script, but I'll see where I am after my project is finished in about

6 weeks.

Message 12 of 15
in reply to: julian.tilbury

I haven't heard about this before and just now I tried to reproduce it but without more specific information about the model and the steps involved I haven't had any success.  When you get a chance it would be good to provide either a set of steps or a simple script that demonstrates the problem.  It's difficult to fix something we don't know how to reproduce but I also understand that it takes time on your side.

Brian Ekins
Inventor and Fusion 360 API Expert
Mod the Machine blog
Message 13 of 15
in reply to: ekinsb

I had to get to the bottom of this to proceed.


The bug only happens when the code is run as an add-in. It runs fine as a script.


1) Create a design and add one user parameter (linear in mm).


2) Sketch a rectangle (or anything)


3) Dimension the rectangle to the user parameter


4) Run the script. It's my parameter manager stripped down to the bug.


5) Undo to 2.


6) Run the script


The add-in can't do a rename, as a script it is fine.


Also note that the undo sequence is different. As a script each rename in the script

is remembered as a transaction.


File attachments box on this forum doesn't think .py is a valid extension!



import adsk.core, adsk.fusion,, traceback


def run(context):

ui = None


app = adsk.core.Application.get()

ui = app.userInterface


docs = app.documents

doc = docs.item(0)

design =


allParams = design.allParameters

userParams = design.userParameters

count = allParams.count


# Save current parameters

save = []

for i in range(count) :

param = allParams.item(i)

if userParams.itemByName ( ) :

save.append ( [True,, param.expression] )

else :

save.append ( [False,, param.expression] )


# Set the expressions to the values so

# as not to screw the design, and there are

# no dependencies

for i in range(count) :

param = allParams.item(i)

param.expression = str(param.value*10)


# Set all userParameter names to blank_0, blank_1 ... blank_n

for i in range(count) :

param = allParams.item(i)

if userParams.itemByName ( ) :

blank = "blank_" + str(i) = blank

if != blank :

ui.messageBox ( "Rename failed. Still " + )


# Restore name to user params

for i in range(count) :

tup = save[i]


user = tup[0]

name = tup[1]

exp = tup[2]


param = allParams.item(i)


if user : = name

# if != name :

# ui.messageBox ( "Rename failed. Still " + )


# Restore expressions to all params

for i in range(count) :

tup = save[i]


user = tup[0]

name = tup[1]

exp = tup[2]


param = allParams.item(i)


param.expression = exp



if ui:


Message 14 of 15
in reply to: ekinsb

Is this because I'm not using commands?


i.e. bracket between a begin & end transaction.


Maybe I have lots of reading tomorrow ...

Message 15 of 15
in reply to: ekinsb

Hi Brian,


You have been very silent on this for nearly two weeks. You usually reply in a day.


Can you reproduce the problem, as posted above?

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th

Autodesk Design & Make Report