TransferFunction Does Not Accept '.' Periods In Argument For "Name" Parameter #1210
Replies: 3 comments 1 reply
|
Periods are now allowed in system names because they are used to reference signals, for example 'sys.u[0]' for the first input of a system named 'sys'. More information here: https://python-control.readthedocs.io/en/0.10.2/iosys.html#signal-based-interconnection |
|
Ok, thank you for clearing that up but still odd since in regular |
|
The problem is how the string is parsed: signal names use periods to separate the name of the system from the name of the signal. So if you name your system 'Ex. 9.4' and then you try to reference the signal 'u[0]' the string you would use is 'Ex. 9.4.u[0]'. The parse isn't fancy enough to tell the difference between system 'Ex' with signal '9.4.u[0]' and system 'Ex. 9.4' with signal 'u[0]'. |
|
Ok, understood. But it would be nice to have a workaround since per original post, we may want to post the transfer function itself which may include periods due to decimal numbers. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello,
as I am working out some exercises, I want to keep track of the bode plots that I am creating by providing the exercise number as the argument for the "name" parameter. However, when attempting to do so, an exception is generated because apparently periods ('.') are not acceptable. Why? A bit surprising since it is a string after all. The argument is passed in as a string, like this:
sys1 = ct.TransferFunction(l3, name='Ex. 9.4')or, if you want to enter the transfer function as the argument so that it can be part of the graph title, as in :
'1 / (1.2s + 4.6s + 4.4s + 1)'This is the error that is generated:
It consistently generates an error if a period '.' is passed in as part of the string argument.
Can the library please be improved so that this is not an issue.
Thank you.
All reactions