251

(5 replies, posted in Elements)

De-Backer wrote:
scorpio810 wrote:

Ready-to-use versions are PORTABLE versions: they don't need to be installed!
Unzip the *.7z archive to a removable media (for example: USB stick) and run the file "Lancer QET.bat".

That's what I use at work, on WIN7 and it works perfectly.

Same for me on win10 (64bit): Works perfectly with all available elements since years!

252

(34 replies, posted in Elements)

@S.DEFFAUX:
I'm not sure, what you mean:
Where do you want to move or copy what elements?
All Symbols and Graphics are in the manufacturer's directory...

@Joshua:
The suggestions I made for additional features inside the elements are meant "for future use"!
I know that it is a great amount of work to implement such features!  EDIT: Especially for doing it on top of the regular work!


But still I think we need some rules for the creation of symbols and graphics:
- separate elements for symbols and graphics
- structure and language of filenames
- language of static texts inside of elements
- maximum number of terminals per schematic-symbol
- splitting of symbols with more than xx terminals
- size / scale of graphics
- (...)

Best regards
  plc-user

253

(34 replies, posted in Elements)

Another thought for schematic- and graphical symbols:
Do we cover the possibility that a real part can have more than one
schematic symbol?

For example:
Like the already available elements for "Johnson Controls" "DX9100",
a complex control-unit may have many digital and analog I/O and extra
communication-ports that meaningfully should be separated in extra
elements to achieve folios that show "readable" and not overloaded
schematics.
There should be the possibility to link these schematic-parts together
and additionally it should be possible to link to a graphic symbol.
This leads to a "master"-part (not a coil) and more than one
"slave"-parts that aren't contacts...

This leads to another idea for schematic symbols:
Do we have the possibility to define a predecessor and successor of a part?
Many (electronic) systems like PLCs are plugged together in a user-defined
order so it should be possible to define such a sequence.

On the other hand a generic part like a switch can contain more than
one real part (real switch, extensions, lever, etc.) that it should
be linked to for graphics and/or part-list.

And even a switch can have auxiliary contacts that can be mounted
together and that leads to slave-contacts of a contact...


Best regards and: Merry Christmas!
  plc-user

254

(34 replies, posted in Elements)

Hello Joshua,

thanks for joining this thread!

That's a good idea: Dimension-Lines can be a real help for drawing an Element!

But before implementing that we need to define some rules for drawing elements:
- What scale (mm <-> px) should a drawing have for Front-View?
- Do we want elements for schematics AND Front-Views AND mixtures of both?
- some other definitions???

When I look at the (electrical) elements of the QET-Collection:
At the moment we have a wild mixture of all varieties!
(see examples in attached file)

A long time ago I learned that a circuit-diagram (German word: Stromlaufplan)
shows how the parts are inter-connected and is not a picture of the switching cabinet.
The whole file can contain a layout-plan (German: Aufbauplan) where one can see
how the switching-cabinet looks like, but the main purpose is to show how the
parts are connected. In a circuit-diagram two parts that are placed side-by-side
to see the function of the circuitry, may be mounted (kilo-) meters apart from
each other!

So in my opinion we should have two main-lines for (electrical) elements:
1 - Elements for circuit-diagrams which show the connections and terminals of an element.
2 - Graphics for Front-Views to use for the layout-plan of a switching-cabinet without terminals.


These explanations and examples may make clear what I mean, when I say:
We need some rules and definitions on how to draw, scale and name our elements.

And when we have defined some rules we have to think about the already available
elements in the collection: Do we re-work all elements? My Pascal-Program can
help on doing this but it is still a great amount of work to do, looking at the
elements to see, if it is for schematic or for front-view, what scale is necessary,
is it a doublette, etc. etc. ...


Besides:
I tried to scale some other elements of the collection but I failed, because in
earlier versions of QET the parts of an element were defined else.
Example:

text-definition in Version 0.50
  <text text="X001" y="-19" size="4" rotation="90" x="53"/>
definition of the same text in Version 0.80
  <text x="53" y="-19" font="Sans Serif,4,-1,5,50,0,0,0,0,0" text="X001" color="#000000" rotation="90"/>

It is not that the scaling fails, but QET 0.8-dev does not understand decimals
for font-size when the file-version is 0.50.
Do you see the chance to have a small tool to walk through the collection-tree
and open all elements and save them again with the actual xml-tags?


Best regards
  plc-user

255

(34 replies, posted in Elements)

Hello S.DEFFAUX!

Who do you want to punish with such work?  nomicons/wink
Checking all existing QET-Elements if they show a
front-view and then scale them by hand...

In the Lazarus-/freepascal-Wiki I found the beginning
of the now existing freepascal-code to take a QET-
Element and scale the content by a factor.

You find the sources and pre-compiled versions for
Debian unstable and ReactOS at
https://github.com/plc-user/QET_ElementScaler

The code compiles/runs with Lazarus 2.0.10 and
FreePascal 3.2.0 on Debian/GNU Linux (unstable) and
ReactOS (0.4.15-dev-1196) (didn't try, but should run
on win7 or 10, too)

In combination with a small shell-script the program
edited all front-views of "my" elements (about 800)
in 1.5 seconds.


But still the main-Question is: What scaling-faktor
do we want to use for front-views of our elements.
In my opinion 100 mm -> 200 px is a good value!
That means that ${someone} has to check, if the already
existing parts use the same scaling-factor. As I wrote
in a previous message: The three examples had three
different factors and I guess there are even more in the
QET-collection ...


Best regards
  plc-user

256

(34 replies, posted in Elements)

Hello everybody,

it seems that we need a little discussion about the scale we want to use for the Front-view:
The three parts S.DEFFAUX added to the folio all have different scales!

DIN-Rail TS35:   100 mm -> 200.00 px
circuit-breaker: 100 mm -> 222.22 px
IO-Module:       100 mm -> 236.00 px

(see also attached file!)

Do we have a specification for the scale of Front-Views?
What documentation did I miss to read?

If we already specified a scale:
Do we have the chance to modify the several hundrets of elements with a script or so?


Regards
  plc-user

257

(34 replies, posted in Elements)

Hello QET-Team,
hello users of QET!

As you may know, I created some hundrets of graphics for the
german manufacturer WAGO as symbols for schematics and front-
views for pictures of the mounting-plate. (No, they do not
pay me for doing this!)

Additional to "my" modules there are some other elements that
are duplicate parts in the meantime.
To harmonise or unify the parts of this manufacturer I would
like to remove the other graphics and move the Sub-directories
"01_schematic" and "02_front" up one level to this structure:

elements/10_electric/20_manufacturers_articles/wago/01_schematic
elements/10_electric/20_manufacturers_articles/wago/02_front

This means that we would drop some files but we will not lose
any parts, because all parts are already included in the sub-dirs!
This procedure would support Claveau Joshua's effort to clean-up
the elements-directory from duplicated parts.

In the attachment you find two parts that I modified slightly
and added to "my" sub-dirs and some examples of graphics that
would be dropped in favour of unified symbols and graphics.

Do you agree with this suggestion?

Best regards
  plc-user

Hallo Volker,

an einem Element kann es zur Zeit entweder nur 1 Potenzial geben oder an jedem Anschluß ein anderes.
(vgl: https://qelectrotech.org/forum/viewtopic.php?id=1460)

Gruß
  plc-user

Hallo Markus,

falls Du alleine mit Deinen vorhandenen Tools arbeiten möchtest, geht auch ein anderer Weg:
- die DWG-Datei mit einem Online-Tool in eine PDF konvertieren
- mit Inkscape die PDF öffnen, bearbeiten und die vereinzelten Teile als DXF speichern
- mit DXFtoQET die Elemente erzeugen
- mit dem Element-Editor nachbearbeiten
- der Community zur Verfügung stellen   nomicons/wink

Die Schritte bis zur SVG-Datei mit Inkscape habe ich ausprobiert: geht ganz gut!
Aber Du brauchst nicht versuchen, die komplette SVG als DXF zu speichern:
DXFtoQET kommt damit nicht klar: Das ist zu groß - Du musst die Teile vereinzeln!

Gruß
  plc-user

Hello De-Backer!

O.k. - I'll keep that in mind!
Thank you!

Regards
  plc-user

Hallo Markus,

was mir aufgefallen ist:
(zumindest) die dxf-Datei "1 Miniserver.dxf" ist korrupt.

Mit "korrupt" meine ich, dass beim Import in Inkscape nur eine Fehlermeldung kommt und dann abbricht:

437 ABSCHNITTE der POLYLINIE aufgetaucht und ignoriert.

Eine Vielzahl meiner Elemente habe ich zunächst mit Inkscape erstellt und daraus dann als DXF exportiert. Die konnte ich dann mühelos mit dem DXF-Konverter zu QET-Elementen konvertieren. (Nacharbeit war aus meiner Sicht trotzdem immer nötig...)

Kenne mich bei DXF nicht wirklich gut aus, aber davon gibt es viele Versionen.
Vielleicht versuchst Du mal, mit Deinem DWG zu DXF-Konverter zu spielen und verschiedene DXF-Format-Versionen zu exportieren. Inkscape kann z.B. als DXF R12 und R14 speichern.

Gruß
  plc-user

Hello De-Backer!

Your manual works perfectly!  nomicons/smile
Thank you!

Already tried the next Pull-Request

Regards
  plc-user

Hallo Volker,

spricht etwas dagegen, dich am "Schaltplan" des Herstellers zu orientieren?

Ich habe mir z.B. eine 6-fach PE-Reihenklemme erstellt (siehe Anhang).
Die Hauptsache  bei solchen Klemmblöcken ist, dass du das Teil in den Bauteileigenschaften als "Klemmleiste" ausweist, damit alle angeschlossenen Leitungen automatisch mit demselben Potenzial versehen werden können.

Hoffe, geholfen zu haben!

Gruß
  plc-user

Hello everybody,

now that the Pull-Request is done and Laurent released the changes it is time to upgrade my fork of the QET-Repo.
Is there a simple way to tell github to upgrade my fork to the (in the meantime changed) original Repo?
I took a quick look but didn't find a simple way...

Regards
  plc-user

Thank you, De-Backer and Laurent!

I will have a look at the videos and be sure: If there are questions, I'll ask!  nomicons/wink

Hello Laurent,

I have no experience on using git, until now.
Can you give me some hints on how to use git for updating elements?
Maybe there is some "howto" for that?

Thanks in advance!
  plc-user

Hello QET-Team!

Is this forum still the place to provide Elements to the project?
It seems that my latest "update" for the Wago-directory was not noticed ...

Regards
  plc-user

created a Bug-Report for this topic:
https://qelectrotech.org/bugtracker/view.php?id=208

Hi Folks,

bug is similar to https://qelectrotech.org/bugtracker/view.php?id=198 but not for the Text itself.
It only affects the SpinEdis for X- and Y-Position, Rotation and Font-Size of regular Text.

Greetings
  plc-user

Hello everybody,

As far as I know, the correct German translation for
"moteur DC excitation séparée"
is
"Gleichstrommotor Fremderregt"

Changed the German translation in the attached file.

Best regards
  plc-user

271

(6 replies, posted in Elements)

Hello jponsa59,

as achim and I already found out and posted in the German part of this forum, the element-editor seems to be broken at the moment.
Have a look here
https://qelectrotech.org/forum/viewtopi … 549#p13549
and here
https://qelectrotech.org/forum/viewtopi … 575#p13575

Best regards
  plc-user

Hallo QET-Team,

wenn im Element-Editor die Position oder die Größe von Text mit Hilfe der Tastatur bearbeitet wird, geht der Fokus nach jedem Tastendruck vom verwendeten SpinEdit weg. Dies macht das Bearbeiten der Text-Eigenschaften ein wenig "zäh", weil das SpinEdit wieder markiert werden muss.

in English:
SpinEdits for Text-Paramters lose focus after every pressed key

aufgefallen unter Debian unstable mit Paket
qelectrotech 0.80.r6839-1
QElectroTech V 0.80-DEV+d3da5a98ac957a06d79751d3
Compilation : GCC 10.2.0
Built with Qt 5.14.2 - Date : Oct 13 2020 : 10:26:56

Gruß
  plc-user

Hallo Achim,
hello all!

bei mir die gleichen Auffälligkeiten:
keine Farben in den Elementen und alle Linien mit demselben Stil!

on english:
Same effects here:
no colors in the Element-Editor and all Lines with solid style.
in diagram-editor everything looks o.k.

Packages on Debian unstable:
QElectroTech V 0.80-DEV+d3da5a98ac957a06d79751d3

and
qelectrotech-0.80-DEV+git6839-x86-win32-readytouse.7z
on Win10

Grüße / Best regards
  plc-user

274

(1 replies, posted in Elements)

Hello QET-Team,

in the directory
elements/10_electric/20_manufacturers_articles/wago/
there is a symbol that does not belong to WAGO.

As the name suggests, the file
cynergy3-ultrasonic-flow-meter-uf25b.elmt
belongs to the manufacturer "cynergy3".

Best regards
  plc-user

Hello QET-Team and QET-users!

Again I re-worked and added some symbols inside the WAGO-Kontakttechnik - Directory.
The Symbols are packed into the attached file.


Best regards
  plc-user