Erroneous feedback connection involving one or more virtual blocks
20 visualizaciones (últimos 30 días)
Mostrar comentarios más antiguos
I copied a model from "Autonomie" (a software based on Simulink). After debugging it I get the error "Erroneous feedback connection involving one or more virtual blocks starting at output port 1 of buscreator_main_info_bus". I have no idea how to solve this, searched some mathworks forums, they say its a bug in Simulink. I am using Simulink version 7.6. Tried feature('BusPropagationForVBlocks', 0); It says an unknown feature was specified. Any help would be highly appreciated. Thanks
0 comentarios
Respuestas (3)
Andreas
el 17 de Jul. de 2013
Ok, my solution was to put gain-blocks (with factor 1) between every bus-signal and to rename the signal afterwards.
0 comentarios
Antonio Palma
el 27 de Nov. de 2013
Hi, Salvation.
If the diagnostic consists of exactly of 11 (eleven) equal messages, your problem is similar to mine.
By using the help I received some years ago from the excellent Official Mathworks Service, I fixed the bug, but the real root cause is not completely clear.
I am almost sure that the problem is in the syntax that Simulink uses (and that has been changing during the years, since 2001) in propagating the line's names (i.e., the optional names you can add to every single signal's line) through "bus creator" and "bus selector" (and, probably, even "mux" and "demux" boxes, that, anyway, I never use). As you know, usually the re-naming of a signal line is often forbidden (when the line name appears automatically inside a double-crochet). But,sometimes, the re-naming of the line is obviously allowed (or even desired, as the trick of "unity gain" adding suggests).
In this way, the same signal could have, in different (part of) sub-models, a different name and, even worse, it could be named differently and (re-)enter in the same (or other ones) "bus creator" or "bus selector". So there could be some bus selectors in which the same signal could be referenced only by different names, although it is the same signal.
In order to temporarily fix the problem, a correct way is to use the "Signal Conversion" block (in its "Bus copy" mode) to break the names' loop.
This trick has, anyway, a drawback: it breaks also the traceability of a signal, letting not anymore possible to trace a signal to its source or to every its destination, stopping it, instead, just on the nearest "Signal Conversion" block itself.
A tecnique that I started to use, in the last five years, is to avoid the re-naming of signals. It seems so simple to say, but, when the systems become complex (as ones I use), so difficult to do!
I hope that my indications have been useful for you. Only, let me know if it has been so, please.
Thank you.
0 comentarios
Andreas
el 17 de Jul. de 2013
I even get this error while using 2012b, 2013a and 2013b beta. The model worked in 2012a and I don't know what happened.
So frustrating...
1 comentario
Kaustubha Govind
el 17 de Jul. de 2013
It's difficult to say anything without looking at the model. Please consider contacting MathWorks Technical Support with the model and reproduction steps to see if they have any insight. Alternatively, you might want to contact the vendor of the model (Autonomie?).
Ver también
Categorías
Más información sobre Simulink Functions en Help Center y File Exchange.
Productos
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!