Archief - De grote automatiseringsthread!

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Bugge

Legacy Member
boostah zei:
Lengte is idd een ander fenomeen dat optreedt, maar ik doelde dat dat onwaarschijnlijk is dat de frequentiedrive er invloed op heeft door de korte afstand dat de kabel der slechts naast loopt/tegen ligt.

Indien vermogenkabels parallel lopen naast signaalkabels/communicatiekabels kan een korte afstand al een probleem zijn, vooral langs de 'vuile' kant van de drive (vermogenkabels naar motor). Steeds de vermogendraden/kabels en signaalkabels laten kruisen (90°) als het niet anders kan, parallel is uit den boze.

Tristan

Legacy Member
Bugge, heb jij toevallig geen goeie info liggen over EMC enzo, als je met hele dagen met drives bezig bent? Over afscherming vermogenkabels, analoge signalen enzo? :)

boostah

Legacy Member
Tristan zei:
Zoiets kun je toch niet echt op afstand oplossen? :/

Agreed, maar de tijd bij de klant, betaald de klant, als die u daar van alles zien proberen en twerkt ni moeten die nog altijd betalen. Daarmee dat er beter intern eerst goed wordt uitgezocht (tis namelijk ook deels kost aan de dienst, aangezien ge erna dezelfde problemen sneller kunt opsporen) om de tijd opt veld te beperken.

Tgrooste probleem (hebben enkele klanten die toeleverancier zijn van autobedrijven) is dat er niet echt veel tijd is voor dingen te checken, uptime is belangrijk (tis nu ni da ze gans plat ligt). Hell zo is er een klant waar bijna altijd alles moet gebeuren tijdens hun aanpassingen (irritant alst fout gaat, moeilijk om te bepalen bij wieh et is enzo, echt een merde), anders ist daar in het kwartier pauze 2 maal per dag het gefixt krijgen, ni fucking easy.

Bugge zei:
Indien vermogenkabels parallel lopen naast signaalkabels/communicatiekabels kan een korte afstand al een probleem zijn, vooral langs de 'vuile' kant van de drive (vermogenkabels naar motor). Steeds de vermogendraden/kabels en signaalkabels laten kruisen (90°) als het niet anders kan, parallel is uit den boze.

Heb ik ook al gedacht. Maar nieuwe kabelgoot bijplaatsen is impossible, maar (en grote maar) op alle andere installaties is dit ook zo, gebruiken dan ook shielded cables voor vermogen. Sterker nog, de installatie die dit vertoont blijkt een van de enigste installaties waar de drives direct op de motor zitten en niet in de kast. Dus een vuil signaal van na de drive bestaat zelfs niet op deze installatie. Begin meer en meer te denken dat shielding van de proficable gewoonweg ergens niet aangesloten is (tis natuurlijk wel altijd mogelijk, maar dubbel shielding en dan nog eens alle andere installaties die het probleem niet vertonen...)


Tristan zei:
Bugge, heb jij toevallig geen goeie info liggen over EMC enzo, als je met hele dagen met drives bezig bent? Over afscherming vermogenkabels, analoge signalen enzo? :)

Moet eens kijken bij siemens, commisioning and guidelines manual die ze hebben derover. Staat online, gewoon zelf effe geen zin om te zoeken :p

boostah

Legacy Member
^MystiQ zei:
Boostah, hoelang is de kabel?

Tvalt mee, tzit ni op zijne limiet (+ de oscilloscoop beelden zijn compleet anders dan moest de impedantie te hoog zijn door een te lange kabel (of te laag door een te korte). Exacte lengte weet ik nog niet, maar kan ik zeggen als ik nog es weer ga (profitrace kan een topology + afstanden weer geven).

Tsignaal is echt nen vette sinus (amplitude 1,5V) gesuperponeerd op den blockwage, een te lange kabel zou reflecties enzo veroorzaken, niet dit fenomeen.


Whiteadder zei:
Active bus termination bij laatste deelnemer?

Bus termination is in orde. Ma doet er mij aan denken een ander vraagske te stellen. In nen manual voorbeeld gevonden van NOT POWERED TERMINATION. Maar ksnap ni wa ze der mee bedoelen (weerstand off als termination is ook een ander, en kdacht toch dat die weerstand geen voltage moest krijgen, of mis ik mij hierin?)

Ps.: kheb de screenshotjes mee, kzal zien vo ze seffes es online te zwieren

^MystiQ

Legacy Member
boostah zei:
Tvalt mee, tzit ni op zijne limiet (+ de oscilloscoop beelden zijn compleet anders dan moest de impedantie te hoog zijn door een te lange kabel (of te laag door een te korte). Exacte lengte weet ik nog niet, maar kan ik zeggen als ik nog es weer ga (profitrace kan een topology + afstanden weer geven).

Tsignaal is echt nen vette sinus (amplitude 1,5V) gesuperponeerd op den blockwage, een te lange kabel zou reflecties enzo veroorzaken, niet dit fenomeen.

Wel opletten he, software kan verkeerde indicaties geven wanneer ge met bepaalde storingen op uw kabel zit. Afstand wordt gemeten aan de hand van reflecties. Welke frequentie heeft diene sinus?

boostah

Legacy Member
^MystiQ zei:
Wel opletten he, software kan verkeerde indicaties geven wanneer ge met bepaalde storingen op uw kabel zit. Afstand wordt gemeten aan de hand van reflecties. Welke frequentie heeft diene sinus?

reflecties dempen uit, deze sinusvorm niet. (wacht op de screenshots, you'll get the picture). Frequentie, geen idee, das de kloterij met die oscilloscoop in profitrace.

Ma software verkeerde indicaties, akkoord, maar ik kijk rechtstreeks op het signaal dmv de oscilloscoop (interpretatie doek zelf maw) en tzou toch wel zeer sterk dat die een beeld geeft van iets compleet anders (ma again, w8 tot ik wa beeld online kan zwieren)

falc.be

Legacy Member
raar maar waar maar ik zit bij een klant waar het absoluut verboden is om LAD of FBD te gebruiken. reden is dat dat een taal is voor elentriekers. het zijn vooral de wat oudere programmeurs die nog van S5 komen die koppig aan stl blijven vasthouden, LAD was geen pretje om in te geven toen.

Mijn voorkeur gaat uit naar LAD. Het programmeren en monitoren gaat makkelijk maar veel belangrijker: veel sneller. Iedere programmeur moet imo wel STL kennen. Ik vind het ook absoluut geen goed ding dat verschillende scholen zelfs geen STL meer aanleren

Ik ben in maart bij siemens naar het TIA portaal gaan kijken maar het is absoluut nog niet volwassen. Siemens raad zelf trouwens af van meteen alles naar TIA portal te converteren, zeker bij bestaande installaties.

V5.5 gaat ondersteunt blijven tot het TIA portaal en V5.5 hetzelfde kunnen, pas dan verdwijnt V5.5. we spreken hier over 2-3 jaar. V11 is hier in ieder geval meteen de kast in gegaan.

Wie werkt hier trouwens met iFIX ?

Ik wordt echt zot van die nieuwe redundancy features sinds 5.0

desondanks nog altijd vele malen beter dan win cc

^MystiQ

Legacy Member
Of ge nu voorstander zijt van V11 of niet, als bedrijven specifiek om de bijvoorbeeld de nieuwe panels vragen van Siemens dan zal je verplicht zijn om over te gaan naar V11. Maar ook ik vind dat Siemens té vroeg is met hun release van V11. Het is momenteel meer bedoeld naar de casual klant en niet naar de industriële klant. Hoe raar dat ook klinkt :p

boostah

Legacy Member
falc.be zei:
Mijn voorkeur gaat uit naar LAD. Het programmeren en monitoren gaat makkelijk maar veel belangrijker: veel sneller. Iedere programmeur moet imo wel STL kennen. Ik vind het ook absoluut geen goed ding dat verschillende scholen zelfs geen STL meer aanleren

Programmeren, disagree, niks is sneller da commando's in te geven (of het SCL of STL is), allesinds pak sneller dan grafisch programmeren. Vergeet gewoon niet da ge STL niet gewoon zijt (en in STL speelt de kracht van uw kennis van accu's en adresregisters veel zwaarder mee). Waarschijnlijk zit ge zelfs met nen hoop nuteloze codes.

Then again, monitoring is echt wel massa's massa's makkelijk met lad of FBD, maar als ge STL gewoo nzijt lukt da daar ook in hoor

^MystiQ

Legacy Member
Ik zou graag eens enkele laddernetwerken hier posten en dan zou je gegarandeerd uw mening herzien. Ik heb hier onlangs een netwerk gezien van welk zeker 100 elementen. Ga dat maar eens debuggen ..

Whiteadder

Legacy Member
boostah zei:
Bus termination is in orde. Ma doet er mij aan denken een ander vraagske te stellen. In nen manual voorbeeld gevonden van NOT POWERED TERMINATION. Maar ksnap ni wa ze der mee bedoelen (weerstand off als termination is ook een ander, en kdacht toch dat die weerstand geen voltage moest krijgen, of mis ik mij hierin?)

WARNING: The cable shield is not always connected to protective ground within all Profibus devices; therefore, make sure the cable shield is connected to ground before it enters the enclosure.

One important point when setting up a Profibus network is where and how to place the termination. Each Profibus peer–to–peer network, or last segment, needs to be terminated at the beginning and end of a segment (must be at the last device). The termination is usually built into the connector. Power must be supplied to the terminating resistors at the device. This means the last device needs to be powered at all times. If you have to replace the last device, the whole network could become unstable. It is preferred that the master device be installed at the beginning of the network and as a termination point.

Copy/Paste uit een manual. Ik had tot voor kort ook nog nooit van active termination gehoord. Feit dat ik zelden met Siemens en Profibus werk, zal wel de reden zijn. Een nieuwe collega maakte mij er onlangs toevallig op attent. Ieder device steekt dus spanning op de termination weerstanden. Valt net dat device zonder spanning of er scheelt iets mee, dan is je termination ook niet meer gegarandeerd. Vandaar dat er dus blijkbaar actieve afsluiters bestaan die (redundant) gevoed worden.
Als voorbeeld gaf hij aan dat ze in zijn vorige firma dus bvb nooit een drive als laatste deelnemer zouden plaatsen en via een gewone PB-stekker de bus zouden afsluiten. Stel dat en drive defect raakt of zonder spanning word gezet om een bepaalde reden, kan dat zorgen voor problemen op je bus.

boostah

Legacy Member
^MystiQ zei:
Ik zou graag eens enkele laddernetwerken hier posten en dan zou je gegarandeerd uw mening herzien. Ik heb hier onlangs een netwerk gezien van welk zeker 100 elementen. Ga dat maar eens debuggen ..

Agreed, maar tis afhankelijk van wat je in dat netwer kdoet, werk je met data is STL SCL aangewezen vind ik zelf (zelfde met jumps). Maar voor de gewone discrete voorwaarden voor een uitgang is het in 99% van de gevallen toch makkelijk om LAD te hebben om te monitoren (meestal bv fotocel da scheef staat).

Btw hoe monitord ge als het in SCL geschreven is?

Whiteadder zei:
WARNING: The cable shield is not always connected to protective ground within all Profibus devices; therefore, make sure the cable shield is connected to ground before it enters the enclosure.

One important point when setting up a Profibus network is where and how to place the termination. Each Profibus peer–to–peer network, or last segment, needs to be terminated at the beginning and end of a segment (must be at the last device). The termination is usually built into the connector. Power must be supplied to the terminating resistors at the device. This means the last device needs to be powered at all times. If you have to replace the last device, the whole network could become unstable. It is preferred that the master device be installed at the beginning of the network and as a termination point.

Copy/Paste uit een manual. Ik had tot voor kort ook nog nooit van active termination gehoord. Feit dat ik zelden met Siemens en Profibus werk, zal wel de reden zijn. Een nieuwe collega maakte mij er onlangs toevallig op attent. Ieder device steekt dus spanning op de termination weerstanden. Valt net dat device zonder spanning of er scheelt iets mee, dan is je termination ook niet meer gegarandeerd. Vandaar dat er dus blijkbaar actieve afsluiters bestaan die (redundant) gevoed worden.
Als voorbeeld gaf hij aan dat ze in zijn vorige firma dus bvb nooit een drive als laatste deelnemer zouden plaatsen en via een gewone PB-stekker de bus zouden afsluiten. Stel dat en drive defect raakt of zonder spanning word gezet om een bepaalde reden, kan dat zorgen voor problemen op je bus.

Merci

^MystiQ

Legacy Member
boostah zei:
Agreed, maar tis afhankelijk van wat je in dat netwer kdoet, werk je met data is STL SCL aangewezen vind ik zelf (zelfde met jumps). Maar voor de gewone discrete voorwaarden voor een uitgang is het in 99% van de gevallen toch makkelijk om LAD te hebben om te monitoren (meestal bv fotocel da scheef staat).

Btw hoe monitord ge als het in SCL geschreven is?

Op exact dezelfde manier als in STL en als in ladder, druk op het brilletje en kijk. :p

Als ge echter niet op het brilletje kunt duwen kan het zijn dat de programmeur in kwestie enkele 'fouten' gemaakt heeft waardoor ge niet kunt monitoren. Ik kan u dat wel eens uitleggen mocht ge meer info nodig hebben.

En geloof mij vrij, zo een laddernetwerk met 100 elementen, dat kan je ook niet zomaar debuggen hoor. De tijd die je nodig hebt om van het begin naar het eind te gaan kijken in zo een netwerk is vrij groot waardoor voor je ziet wat er op het einde gebeurt, uw eerste condities al weer volledig veranderd kunnen zijn.

boostah

Legacy Member
^MystiQ zei:
En geloof mij vrij, zo een laddernetwerk met 100 elementen, dat kan je ook niet zomaar debuggen hoor. De tijd die je nodig hebt om van het begin naar het eind te gaan kijken in zo een netwerk is vrij groot waardoor voor je ziet wat er op het einde gebeurt, uw eerste condities al weer volledig veranderd kunnen zijn.

Akkoord, maar maak dan logische tussenvoorwaarden. Kan me niet inbeelden bij iets van 100 contacten, dat er geen logische tussenstaps zijn die een aparte vw kennen. Om die dan opt einde samen te voegen. Laat het mij zo zeggen, lijkt mij eerder geen goeie programming practice om het zo te doen.

rabsi

Legacy Member
boostah zei:
Programmeren, disagree, niks is sneller da commando's in te geven (of het SCL of STL is), allesinds pak sneller dan grafisch programmeren. Vergeet gewoon niet da ge STL niet gewoon zijt (en in STL speelt de kracht van uw kennis van accu's en adresregisters veel zwaarder mee). Waarschijnlijk zit ge zelfs met nen hoop nuteloze codes.

Then again, monitoring is echt wel massa's massa's makkelijk met lad of FBD, maar als ge STL gewoo nzijt lukt da daar ook in hoor

Ik heb liever dat een programma zo overzichtelijk mogelijk is, snelheid staat niet bovenaan de prioriteiten lijst. (snelheid die gewonnen wordt bij programmeren, heb je meestal later dubbel en dik terug bij debuggen en latere aanpassingen aan de sturing). (Heb graag dat programma ook voorzien wordt van voldoende commentaar, zodat iemand die 10jaar later het programma moet analyseren er niet te lang moet zitten op zoeken)

Persoonlijk heb ik een voorkeur voor een programma in LADDER waarin FB's/FC's gebruikt worden voor het overzicht te bewaren. Die FB's FC's kunnen dan eventueel in STL geschreven zijn, zeker als het is voor berkeningen/regelkringen ect.. Want dat is te omslachtig in LAD

En voor de monitoring is dat niet eenvoudiger als ge daarvoor een Tabel aanmaakt waarin alles staat dat ge wilt monitoren.

Bijkomende vraag: Ik zou graag datlogging doen van nen FX3U PLC (Mitshibushi) op nen PC over ethernet, Ik zou daarvoor een java programma willen programmeren. Bestaan er al standaard java classes die iets inlezen van de PLC ? momenteel gebruik ik MX sheet voor de datalogging maar ben hiermee beperkt door excel.

Indien die niet bestaan bestaan die dan wel Siemens PLC 300 400 reeks ?

jvc

Legacy Member
Voor .NET bestaan er opc wrappers die je gemakkelijk vindt op het internet, ik veronderstel dat dit voor java ook wel te vinden is :)

^MystiQ

Legacy Member
Rabsi, commentaar in een programma is de grootste bullshit die er bestaat. Als je een programma deftig geschreven hebt moet iedereen daar wijs aan geraken wat er precies geprogrammeerd is.

Want commentaar is het laatste die up to date gehouden wordt in een programma en het gevaar bestaat dat er commentaar blijft staan in programma's die soms zeer misleidend kan zijn. Daarom proberen wij voor nieuwe projecten zelden commentaar te voorzien tenzij de klant daar specifiek om vraagt of tenzij er bepaalde stukken code zijn die nooit zullen veranderen. Een voorbeeld kan zijn het inlezen van een encoderwaarde die dan herberekend wordt.

sparco

Legacy Member
Ik vraag me af hoe het niveau van PLC op jullie school was. Hebben jullie altijd in STL moeten werken? En wat voor leerstof hebben jullie dan allemaal gezien? :)

Ikzelf volg een bachelor elektromechanica, en ik heb precies de indruk dat het niveau niet echt hoog is.

Wij hebben in't eerste jaar de basis gekregen; een beetje STL, wat LAD, maar vooral FBD.

En dan in het 2de jaar énkel met FBD ( Met uitzondering van wat waardes wegschrijven naar een DB in STL)

We hebben leerstof behandeld met betrekking tot multi instantie DB's, analoge ingangen, encoders, functieblokken, etc.

Maar ik heb het gevoel dat ik echt nog niets fatsoenlijk kan, voor in een bedrijf, ivm met PLC.
Welke mogelijkheden zijn er om mezelf verder te verdiepen in PLC? :)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan