Forum
Important Notice for New User Registrations
To combat an increasing number of spam and bot registrations, we now manually approve all new user registrations. While this may cause a delay until your account is approved, this step is essential to ensure the quality and security of this forum.
To help us verify your registration as legitimate, please use a clear name as user name or an official email address (such as a work, university, or similar address). If you’re concerned that we may not recognize your registration as non-spam, feel free to email us at with a request to approve your username.
The structural model diverged when a bladed-type controller was added
Hello David,
Thanks again for your comprehensive reply. After a few more tests, I discovered that the problem was rather the opposite. In fact, the pointer used by QBlade to find the .in file was always the same at each time step. However, the values of these lines were only initialized in the case of status 0, i.e. on the very first function call. To make this work, I’ve changed this to read the .in file each time the DISCON function is called. It’s quite strange but a cleanup is done at each time step when QBlade returns the swaparray for certain values (especially for the .in file, but the measured torque for example is not equal to 0),
Thank you very much for your assistance all the way to solve the problem,
Best regards,
Hugo
Hi Hugo,
I’m glad to hear that you managed to solve the problem.
Regarding the accINFILE parameter, it does not change at all during successive calls to the DISCON function. The only aspect that changes in QBlade between the first call and subsequent calls is that QBlade alters its “current directory”—an internal state of the QBlade application—to the /TEMP directory containing the controller library and .in file, and this change only occurs beforethe first call of the discon function.
Additionally, you are correct about the swap array: it is not intended to store any values persistently, as it is reinitialized at every timestep before the DISCON function is called. To store configuration values persistently (such as those read from the .in file), you would need to define a persistent array or a set of variables within your controller library. Alternatively, you can of course also re-read hese values from the .in file at every timestep, even if this is not intended in the design of the DISCON interface.
BR,
David
