SimplifiedLogic / creoson

OpenSource Automation using JSON Transactions for PTC's CREO Parametric
http://www.creoson.com
MIT License
81 stars 23 forks source link

parameter : set list #34

Closed dmtr99 closed 4 years ago

dmtr99 commented 4 years ago

The function "parameter : set" works great I use it a lot. Is it possible to give the command to modify multiple parameters? This would speed up the process if you need to modify a lot of parameters. ! The error handling in this case would also need to return an error if an error or error occured.

or is it maybe possible to send multiple commands to Creoson and recieve multiple responses?

{
  "sessionId": "~sessionId~",
  "command": "parameter",
  "function": "set list",
  "data": {
     "paramlist": [
         {
            "file": "box.prt",
            "name": "TEST",
            "type": "INTEGER",
            "value": 32
        },
        {
            "file": "box.prt",
            "name": "TEST2",
            "type": "STRING",
            "value": "This is an example"
        }
  }
}
davidhbigelow commented 4 years ago

This has been a subject of debate internally for some time - specifically symmetric vs asymmetric execution of commands.

There are a couple of factors that are of key concern:

1) the limit of Creo's API to accept parallel requests 2) the possibility of executing things in the wrong order based on the random arrival time/processing of asymmetric requests. 3) the user's ability to anticipate this and not do something stupid (like erase memory in the midst of setting a prameter elsewhere or regenerating prematurely).

If we were to, for the sake of convenience, execute a large object of commands (pass a huge structure to just do something without you having to code the steps and error handling) - then we are just normalizing the execution process - forcing a standard for how things should be done.

We kind of do this with Nitro-CELL - allow the steps defined in Excel to be passed off and worked ... but it is still a symmetric execution process (one step first then the next). We have been in debate for years about the possibility of improving that product to enable parallel requests - but then it still comes back to "can creo handle it?" and "how do we prevent supid stuff from happening?"

I think the suggestion is good - but I am not seeing major changes here.

About the only thing I can see would be to make the parameter set command have similar functionality to the list function (e.g. name and names vs just name). But all that is really doing is allowing you to send one request with multiple objects within it and deal with one error that you would have to parse the problem for... THEN there is the problem of "what got rolled back in creo on a failure? do we step over errors and continue or stop? or do we just roll back the entire transaction (which will be not easy)?"

Seems like it would be better to not introduce a higher level -- until we can really think about the ramifications of that.

Dave

On Mon, Oct 28, 2019 at 11:02 AM dmtr99 notifications@github.com wrote:

The function "parameter : set" works great I use it a lot. Is it possible to give the command to modify multiple parameters? This would speed up the process if you need to modify a lot of parameters. ! The error handling in this case would also need to return an error if an error or error occured.

or is it maybe possible to send multiple commands to Creoson and recieve multiple responses?

{ "sessionId": "~sessionId~", "command": "parameter", "function": "set list", "data": { "paramlist": [ { "file": "box.prt", "name": "TEST", "type": "INTEGER", "value": 32 }, { "file": "box.prt", "name": "TEST2", "type": "STRING", "value": "This is an example" } } }

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SimplifiedLogic/creoson/issues/34?email_source=notifications&email_token=AAMSRJK7PBX2ICNBR2F5RUTQQ35I7A5CNFSM4JF3OBQ2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HUZI23A, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMSRJJDG2REFCKA6YKZRVTQQ35I7ANCNFSM4JF3OBQQ .

-- David Bigelow, President Simplified Logic, Inc https://www.simplifiedlogic.com | SimilarParts.ai C: 317-431-5454

adama2000 commented 4 years ago

Well, adding a "names" argument would just let you set multiple parameters to the same value. To set them to different values would require an input structure similar to what dmtr99 gave.

But I agree that it makes more sense to just make multiple calls to the existing parameter-set function; the amount of processing time should be about the same, and I think the coding on your side would actually be simpler. And that avoids the issue of how to deal with errors that Dave mentioned.

dmtr99 commented 4 years ago

This function would just exist to have a faster way to write parameter then calling parameter : set multiple times. But if the speed is almost the same, it is more interested to use parameter : set. This way you can easily keep track of wich parameter is set.

The issue of dealing with errors can be quite simplefied:

davidhbigelow commented 4 years ago

Not disagreeing that there are ways to address failures and handling for this type of request.

In the end - it is passing off to a synchronous execution into Creo --- so it would not be faster ... it is just moving the loop from your end as a developer to our end as the one executing the request into Creo.

If you want to code up a fork of this to evaluate as a contribution I think we would take a closer look. But this should also consider dimensions and notes for similar functionality.

Closing this for now.

On Mon, Oct 28, 2019 at 3:11 PM dmtr99 notifications@github.com wrote:

This function would just exist to have a faster way to write parameter then calling parameter : set multiple times. But if the speed is almost the same, it is more interested to use parameter : set. This way you can easily keep track of wich parameter is set.

The issue of dealing with errors can be quite simplefied:

  • If error = false: go to the next parameter
  • if error = true: break command, return the error with identification of at wich command it occured.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimplifiedLogic/creoson/issues/34?email_source=notifications&email_token=AAMSRJNEJ6R27CB24UE5DPTQQ42NPA5CNFSM4JF3OBQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECOB2RA#issuecomment-547102020, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMSRJMH2L4ZBHUY2FMEF6LQQ42NPANCNFSM4JF3OBQQ .

-- David Bigelow, President Simplified Logic, Inc https://www.simplifiedlogic.com | SimilarParts.ai C: 317-431-5454