Search options

Da kannst du wahrscheinlich nur ein eigenes Bauteil erstellen, das nicht vom Typ Klemme ist. Damit verliert es aber auch die Eigenschaft, dass alle angeschlossenen Drähte gemeinsam aktualisiert werden, also eine logische Verbindung der Potenziale in QET erfasst wird.

In einer kommenden Version werden die Felder auch bei Klemmen-Bauteilen verfügbar sein, wenn ich das letztens richtig gelesen habe.

Open it in QCAD (or LibreCAD, almost the same) - not in QElectroTech.  Then the instructions apply.

To save this step in the future, teach your Illustrator to not make DXF "blocks" from grouped elements or shapes.

Sorry die Bilder schaffen mir keine zusätzliche Klarheit. Was genau willst du erreichen? Das ist doch ein Relais und alle Kontakte sind normalerweise völlig unabhängig?

Hallo Muecke,

wenn du dein modifiziertes Bauteil ein weiteres Mal aus der Bibliothek platzierst, wird es im Projekt angepasst und beim nächsten Öffnen siehst du überall die neue Version.

Das funktioniert allerdings nicht für die Texte. Diese werden für jedes platzierte Bauteil separat gespeichert und nicht mehr aus dem Template Element aktualisiert. Eine Möglichkeit, das zu umgehen, wäre die Texte einer neuen Instanz als Textkonfiguration zu speichern. In den alten Instanzen kann diese dann wieder geladen werden, wobei die Option "alte überschreiben" (oder so ähnlich) aktiv sein sollte. Sofern die Bauteile sich nur in Texten unterscheiden, die über Attribute definiert sind, geht das recht problemlos. Jedenfalls müssen keine Verbindungen neu gezogen werden.

Viel Erfolg und schöne Grüße!
André

I've been using the "Function" field of the wire to store what the channel is assigned to.  It works quite well together with folio references, which you can define and style yourself.  A folio reference can include a dynamic text element for its "Function" attribute, which automatically displays the Function of the connected wire (on both ends when linked together).

Attached sample project shows a little of this in action:

1. A physical view of each PLC component. This is declared as a "master" element type so that others can be linked to it. The linking results in a nice table of references where this component is referenced.

2. A logical view of each connector of the PLC components. These are declared as "slave" element type and get linked to the physical view. That automatically makes the master's properties available for text display, such as the module type and of course its ID (with a back-reference to the folio with the physical view).

3. A generic "signal description" element declared as type "previous_report".  It has a single pin that gets connected to the logical PLC connector element.  This connection (wire) then gets assigned a Function attribute naming what the channel is used for.  It automatically displays the Function and has a spare text field by default that is used to record the logical input / output number as a reference for the software developer.  These pages give you a nice overview of what channels are assigned and for what they are used.

4. The opposite "next_report" element type is drawn as a "channel header". It gets inserted wherever in the schematic the channel is needed (though limited to one place per channel).  It again has a dynamic text field displaying the Function attribute value.  Link this element to the previous one, which is rather easy to do because the possible link targets table shows the Function value, so you just need to pick the semantic name you've given the channel's signal.  Note that this "header" element could be used stand-alone, connecting its pin to the sensor directly.  But that doesn't work for the case of analog differential or RTD inputs, where several pins are required for the channel.  Thus there's a standardized "channel body" element as well, see below.

5. The "channel body" element exists in different variants, for example 1 to 4 used pins.  It is declared as element type "slave" again, to be linked to the physical module representation.  That makes it clear where the signals are connected to, and pulls in the referenced module type attribute again, so you easily see that it's an analog input for example.  It has an almost unnoticeable pin on the top-left corner which is designed to automatically connect to the "channel header" element, to make sure there's a connection and the Function attribute is actually displayed.  For the individual pins, there are separate text fields to describe exactly on which terminal of the module the channel resides.  This is unfortunately still a manual process, you need to jump back to the linked "signal description" (just double-click the folio link), remember which terminal(s) the signal is connected to, jump back (another double-click) and adjust the texts.  Doing it manually has the advantage that you can pick the order for multi-terminal channels, such as 4-wire RTD inputs, to untangle your connections.

It's a bit of work to get the PLC-specific parts set up first (because the existing library symbols have no master-slave relations there), but I think it's worth the effort.  Remapping a channel is done with a few clicks and some manual text updates.  Note that if you really need the same channel referenced in more than one place in your schematic, you could still place more "signal description" elements connected to the same PLC terminal.  I've done that for Modbus channels for example, where it nicely summarizes references to all Modbus-connected sensors.

Overall I guess I'm a programmer, used to stuff being generated for me based on a single declaration, and error-checked by the compiler.  QET is more of a "smart pencil" so I wanted to make as much as possible automated and linked together to avoid mistakes and mismatching references.  More features in this direction, allowing to link stuff together on a semantic level, would of course be great.

As you've shown now, it's quite easy to use.  If we ever need to distribute it in some other way, I'll look into creating a proper runnable Python package.

Happy it worked for your project, are the results correct?  I see there are mentions of a terminal block "XI", but there is no diagram for it.  Is that a connector on some device?  Of course the results there are wrong because the label "XI:24E2" is interpreted by SQLite as having the number

24e2 = 24.0 * 10^2 = 2400.0

Thus it generates these 2400 rows for that block.  You'd need to fix up the naming there to use only integers after the colon.  The other blocks seem fine, just that your existing diagrams actually do have duplicates, e.g. XANA:2.  What does it physically look like, are there two terminal strips next to each other, or is it actually just two connections to one strip?

Thanks for the AppImage pointer, that's actually what I'm using right now.  Just that flatpak notifies me about upgrades automatically and I prefer using it (over e.g. snap) for most software.  Hope you can resolve the build issues.  Wouldn't you just need to adjust the patch in the upstream QET repository, instead of the flathub repo?  Haven't looked closely, but that's where I would have started to look.

That looks pretty cool indeed, thanks for pointing it out. I'm eager to try it out in the next released version.

Until then, I need a stable solution though, based on software that I can point a customer to - no development version which is a moving target and things might just stop working at some point because they were generated with an intermediate development snapshot. Sorry I can't get much more involved with QET development, but rather just consume the stable version releases as they come. What a great software by the way, thanks to all the people making this a reality as FOSS!

Publishing my own little addition as FOSS is my way to give back to the community for being able to use a completely free CAE drawing software.