Ladderhome è Ladderwork?

[ffolks]

Qualcuni sa dirmi se Ladderhome è il nome che homeplc ha dato al software ladderwork per core 8051?

Grazie.

[del_user_56966]

Qualcuni sa dirmi se Ladderhome è il nome che homeplc ha dato al software ladderwork per core 8051?

Sono due prodotti tra loro differenti anche se entrambi basati sul solito compilatore...

[ffolks]

Grazie per l'informazione.

[ffolks]

Domando ad Aleandro, visto il notevole knowhow in tema di homeplc, se, qualora noti gli indirizzi der registri di I/O dell'8051 dell' homeplc, essi siano programmabili in ASM 8051 o C51?

Se si, sono disponibili in forma pubblica gli indirizzi (ovvero, ad ingresso 1 dell'homeplc modello xxxx, corrisponde porta PB.1 dell'8051, etc).

E' nota marca e modello del core 8051?

Grazie.

[del_user_56966]

Domando ad Aleandro, visto il notevole knowhow in tema di homeplc, se, qualora noti gli indirizzi der registri di I/O dell'8051 dell' homeplc, essi siano programmabili in ASM 8051 o C51?

Se si, sono disponibili in forma pubblica gli indirizzi (ovvero, ad ingresso 1 dell'homeplc modello xxxx, corrisponde porta PB.1 dell'8051, etc).

no, l'indirizzamento non è basato sugli indirizzi fisici come nelle normali applicazioni ladderwork,

tu utilizzi il ladderwork?

[ffolks]

L'IDE della microshadow l'ho utilizzata solo per verificare l'ottimizzazione del codice asm generato direttamente, in quanto gli autori dicono di effetuare la compilazione LADDER --> ASM direttamente, senza pseudocodice C.

Direi che è prolissa tanto quanto quella generata da un compilatore C, ma è solo il mio parere.

Inoltre il progetto Ladderwork mi sembra abbandonato (demo datate 2003) documentazione del 2000, nessun upgrade, l'ultima news risale forse al 2007.

Spero che LadderHome di HomePLC sia una evoluzione di Ladderwork, da cui, mi sembra di capire, deriva.

Il mio uso di LadderWork si ferma qui.

Personalmente preferisco altri linguaggi per un PLC (che giratela come volete, è una mcu con carrozzeria, al meglio un normalissimo PC con un softPLC a livello di kernel ), il ladder è limitante, ma va benissimo per un impianto domotico.

HomePLC, a livello hardware, lo trovo interessante come prodotto domotico alternativo ai soliti noti (un solo appunto, l'estetica!!!! va in casa non in fabbrica)

La vera limitazione del sistema ritengo sia la mancanza di un simulatore, quantomeno, non mi sembra che LadderHome sia in grado di girare in modalità simulazione.

Poco male, con co***ys o similari (metto gli asterischi perchè non so se si possa scrivere di altri sw) ed una piccola dose di pazienza, si può simulare e testare virtualmente l'intero sistema HomePLC. Peccato che non si possa compilare.

La richiesta di conoscere i dettagli hardware dei prodotti HomePLC (mcu e relativa schematica esterna) è dettata dal fatto di voler utilizzare linguaggi che non siano il ladder o FDB e realizzare un simulatore hw/sw degli apparati HomePLC.

Quindi, grato a chiunque sia in grado di fornirli.

[mshadow65]

Ci sono delle cose non propriamente corrette a riguardo di LadderWORK

- LadderWORK generico per 8051 non e' piu' aggiornato dal 2007. La versione

general purpose per questo tipo di core, che e' ovviamente inirizzata ad un

pubblico hobbistico e studentesco, non e' di particolare interesse per l'azienda

- La versione demo e' in rete a scopi solamente dimostrativi e didattici

- MicroSHADOW Research sta sviluppando ed adattando LadderWORK SOLO

per i clienti con cui e' stato sottoscritto un contratto di cooperazione

continuativa con l'azienda

- MicroSHADOW Research sta sviluppando LadderWORK su altri cores

piu' performanti.

- MicroSHADOW Research vanta un parco mondiale di aziende che

utilizzano il motore LadderWORK nei loro sistemi

Gianluca

[del_user_56966]

Spero che LadderHome di HomePLC sia una evoluzione di Ladderwork, da cui, mi sembra di capire, deriva.

Concordo con la tua analisi di LadderWork, sicuramente è un prodotto valido per l'uso per cui era concepito a suo tempo,

ma sicuramente oggi ha bisogno di una bella revisionata...

Personalmente preferisco altri linguaggi per un PLC (che giratela come volete, è una mcu con carrozzeria, al meglio un normalissimo PC con un softPLC a livello di kernel ), il ladder è limitante, ma va benissimo per un impianto domotico.

Diciamo che rispetto ad altre soluzioni questa offre sicuramente una similitudine con quella

"che giratela come volete" è a tutti gli effetti un automazione, e quando si parla di automazione i linguaggi per eccellenza

sono quelli da sempre utilizzati e oggi standardizzati nella EN61131-3

La vera limitazione del sistema ritengo sia la mancanza di un simulatore, quantomeno, non mi sembra che LadderHome sia in grado di girare in modalità simulazione.

In effetti dopo un attenta analisi penso vi siano vari motivi per cui queste tecnologie non sono del tutto simulabili o perlomeno

non cosi facilmente come per un normale PLC o sistema che si componga solo di I/O analogici o digitali...

Poco male, con co***ys o similari (metto gli asterischi perchè non so se si possa scrivere di altri sw) ed una piccola dose di pazienza, si può simulare e testare virtualmente l'intero sistema HomePLC. Peccato che non si possa compilare.

Io penso che tu conosca il ladderWork ma che tu non cosi bene il sistema HomePLC, come ti dicevo prima la maggior

parte delle funzioni oltre quelle visibili dal Ladder non mi sembrano simulabili, tanto meno tramite altri software salvo che non

siano ottimizzati per questo tipo di applicazioni...

La richiesta di conoscere i dettagli hardware dei prodotti HomePLC (mcu e relativa schematica esterna) è dettata dal fatto di voler utilizzare linguaggi che non siano il ladder o FDB e realizzare un simulatore hw/sw degli apparati HomePLC.

Quindi, grato a chiunque sia in grado di fornirli.

Potresti sicuramente realizzare una simulazione di una parte delle potenzialità del sistema HomePLC, simularle tutte secondo me è

improbabile, questa chiaramente è solo una mia sensazione, quello che vedo è che il sistema HomePLC è sviluppato da più

società e avendo modo di parlare singolarmente con queste

si ha il sentore che ognuna conosca perfettamente il proprio lavoro ma che se interrogate su argomenti diversi dal proprio ambito

di sviluppo non abbiano una visione completa del sistema ...

Oltre questo quale soluzione HomePLC vorresti simulare,

PLC Domotico + Sistema di I/O HP,

PLC + Sistema di I/O HP

PC Panel + Sistema di I/O HP

Scada + Sistema di I/O HP

Embedded + Sistema di I/O HP

ecc...

sono tutte soluzioni che rientrano nella sfera di applicazioni HomePLC ma possono essere molto lontane tra loro, l'unica cosa che

rimane standard tra loro è il sistema di I/O...

una soluzione con PLC Domotico + HomePLC I/O può essere completamente differente

da un applicazione Linux + HomePLC I/O....

[del_user_56966]

- MicroSHADOW Research vanta un parco mondiale di aziende che

utilizzano il motore LadderWORK nei loro sistemi

Eila! Gianluca, in effetti da ricerche su Internet si nota una forte attività di LadderWork in paesi come India, Cina, Korea ecc...

sarà mica per quello che hanno il PIL in crescita...

[mshadow65]

<Direi che è prolissa tanto quanto quella generata da un compilatore C, ma è solo il mio parere.>

LadderWORK e' l'unico compilatore al mondo in grado di far girare codice su single chips.

Esistono piattaforme 8051, e supportate da LadderWORK, dotate di 2K di Flash (2048 Bytes) e 64 bytes di RAM (sessantaquattro).

Il compilatore genera direttamente codice assembler senza la necessita' di ulteriori processi e

quindi "rigonfiamenti"

Tutta la RTL (Run Time Library) di LadderWORK e' stata scritta interamente in linguaggio

Assembly per migliorare in maniera massiccia sia la compattezza del codice che la sua velocita'

di esecuzione

La natura di LadderWORK e' ben chiara. Sin dalle sue prime versioni rilasciate nel 1997 il

software aveva come obbiettivi quello di poter trasformare un qualunque chip 8051 in

un potente PLC. Vi sono prodotti basati su LadderWORK che hanno, in produzione, un costo

che si aggira intorno ai 30-40 euro. Nessun altro prodotto analogo ha requisiti cosi'

minimali in termini di potenza di calcolo e consumi di memoria. Lo slogan di MicroSHADOW

e' sempre stato "Put a PLC into your microcontroller". Vi sono chips 8051 che sono sotto il dollaro$

di costo. Per far girare LadderWORK basta questo ... nient'altro ....

Non mi sembra che questo possa essere considerato "prolisso"

Versioni High-End di LadderWORK sono ovviamente basate su tecnologie e scelte

funzionali diverse.

Gianluca

[ffolks]

Relativamente a LadderWork, mi fa piacere che migliaia di aziende usino una versione avanzata e non pubblicizzata, ma quella che si trova sul sito come demo ( e con la scritta lampeggiante NEW) è quella che ho potuto usare per una mia prova.

Scusami, ma non ti puoi lamentare se poi ricevi dei commenti che non gradisci. Sono le basi del marketing, è come se microsoft ti dicesse di valutare il suo ultimo s.o. windows 7 e poi ti fornisca come s.o. funzionante una versione di windows 95 o peggio 3.11 ?.

Come commenterebbero gli utenti in questo caso?

Senza nulla togliere a Ladderwork, ma di compilatori Ladder ne esistono altri ed anche opensource, basta cercare su google.

Per prolisso intendo il list che il compilatore demo fornisce per far lampeggiare un led è proprio... prolisso. Vedi esempi al termine del post.

Alla fine della discussione intendevo proprio questo; ritenevo che ladderwork demo riuscisse a creare codice più compatto.

Ci potrebbero essere altri esempi, da C51 ad ASM, da BASCOM8051 a ASM.

Tutto qui, il che, non significa che il compilatore ladderwork non sia valido, il suo lavoro lo fa.

Il punto è che a me non piace avere una tonnellata di codice in memoria quando posso ridurlo.

Ovviamente non posso usare un compilatore ladder per raggiungere questo fine, il che mi riporta alla mia affermazione, preferisco altri linguaggi al ladder.

Poi che il ladder sia uno standard (IEC 61131-3) nel mondo plc non si discute, ma lo sono anche FDB, IL, ST e SFC.

ESEMPI:

Questo è codice 8051 per far lampeggiare un led:

**********************************************

MCS-51 Family Macro Assembler A S E M - 5 1 V 1.3

=====================================================

Source File: blinky.asm

Object File: blinky.hex

List File: blinky.lst

Line I Addr Code Source

1: N 0000 org 0h

2: 0000 start:

3: 0000 C2 90 Clr P1.0 ;send '0' to P1.0

4: 0002 12 00 0C call delay ;call delay time

5: 0005 D2 90 Setb P1.0 ;send '1' to P1.0

6: 0007 12 00 0C call delay ;call delay time

7: 000A 80 F4 sjmp start ;loop forever to start

8: ;=============================================

9: ;subroutine delay created to rise delay time

10: ;=============================================

11: 000C 79 FF delay: mov R1,#255

12: 000E 7A FF del1: mov R2,#255

13: 0010 DA FE del2: djnz R2,del2

14: 0012 D9 FA djnz R1,del1

15: 0014 22 ret

16: end

questo è quello che fornisce il compilatore ladderwork:

;-------------------------------------------------------------------

; MicroSHADOW Research (uS)

; FBD/LADDER Compiler generated code

; Compiler Release : Release 1.71.A - 28.12.2002

; Compiling launched Sat Oct 17 15:10:53 2009

;-------------------------------------------------------------------

; ----------------------------------------------

; Function : LWSTARTUP (ladrwork[00])

; ----------------------------------------------

include"memory.inc"

TIMER_PERIOD EQU 50

; ----------------------------------------------

; Function : LWMAIN/BASEMODULE (ladrwork[00])

; ----------------------------------------------

dseg

public __FIRSTCYCLE__

__FIRSTCYCLE__:ds 1

cseg

PUBLIC _lwmain

_lwmain:

mov __FIRSTCYCLE__,#1

mov r0,#__AREA_BOOL__

mov[at]r0,#1

lcall __begin_init

lcall __postinit

extern __var_init

lcall __var_init

extern __AdvancedInit__

lcall __AdvancedInit__

; ----------------------------------------------

; Function : LWMAIN/BASEMODULE (panel[00])

; ----------------------------------------------

rseg fields,code

public __fields__

__fields__:

rseg fddata,data

public __fields_data__

__fields_data__:

cseg

; ----------------------------------------------

; Function : LWMAIN/MPU8051 (MPU8051[06])

; ----------------------------------------------

INCLUDE"KERNEL.INC"

INCLUDE"SFR8051.INC"

cseg

; ----------------------------------------------

; Function : OPENCYCLE (ladrwork[00])

; ----------------------------------------------

__Forever__:

; ----------------------------------------------

; Function : SOC/MPU8051 (MPU8051[06])

; ----------------------------------------------

cseg

mov r0,#__IO_MIRROR__+(0*4)+0 ; R:(__MODULE__) R:(__SLOTSIZE__)

mov a,P0

xrl a,#BINNOT(0) ; R:(__PMASK_P0_POL__)

mov[at]r0,a

mov r0,#__IO_MIRROR__+(0*4)+1 ; R:(__MODULE__) R:(__SLOTSIZE__)

mov a,P1

xrl a,#BINNOT(0) ; R:(__PMASK_P1_POL__)

mov[at]r0,a

mov r0,#__IO_MIRROR__+(0*4)+2 ; R:(__MODULE__) R:(__SLOTSIZE__)

mov a,P2

xrl a,#BINNOT(0) ; R:(__PMASK_P2_POL__)

mov[at]r0,a

mov r0,#__IO_MIRROR__+(0*4)+3 ; R:(__MODULE__) R:(__SLOTSIZE__)

mov a,P3

xrl a,#BINNOT(0) ; R:(__PMASK_P3_POL__)

mov[at]r0,a

; ----------------------------------------------

; Function : CLOCK/CLOCK (ladrwork[00])

; ----------------------------------------------

extern __clock

mov r0,#CLOCK_CLK1 ; R:(REFERENCE)

mov r5,#LOW((1000000/1000)/TIMER_PERIOD) ; R:(FREQUENCY)

lcall __clock

; ----------------------------------------------

; Function : CLOCK/OUT (ladrwork[00])

; ----------------------------------------------

extern __clock_out

mov r0,#CLOCK_CLK1 ; R:(REFERENCE)

lcall __clock_out

; ----------------------------------------------

; Function : OUTPUT/B (iomem[02])

; ----------------------------------------------

cseg

mov r0,#__IO_MIRROR__+(0*4)+1 ; R:(__ADRLEVEL1__) R:(__SLOTSIZE__) R:(__ADRLEVEL2__)

rrc a

mov a,[at]r0

mov ACC.0,c ; R:(__ADRLEVEL3__)

mov[at]r0,a

clr a

rlc a

; ----------------------------------------------

; Function : EOC/BASEMODULE (ctrl_watch[01])

; ----------------------------------------------

cseg

; ----------------------------------------------

; Function : EOC/BASEMODULE (nvmemory[01])

; ----------------------------------------------

cseg

; ----------------------------------------------

; Function : EOC/MPU8051 (MPU8051[06])

; ----------------------------------------------

cseg

mov r0,#__IO_MIRROR__+(0*4)+0 ; R:(__MODULE__) R:(__SLOTSIZE__)

mov a,[at]r0

xrl a,#BINNOT(0) ; R:(__PMASK_P0_POL__)

orl a,#255 ; R:(__PMASK_P0_DIR__)

mov P0,a

mov r0,#__IO_MIRROR__+(0*4)+1 ; R:(__MODULE__) R:(__SLOTSIZE__)

mov a,[at]r0

xrl a,#BINNOT(0) ; R:(__PMASK_P1_POL__)

orl a,#254 ; R:(__PMASK_P1_DIR__)

mov P1,a

mov r0,#__IO_MIRROR__+(0*4)+2 ; R:(__MODULE__) R:(__SLOTSIZE__)

mov a,[at]r0

xrl a,#BINNOT(0) ; R:(__PMASK_P2_POL__)

orl a,#255 ; R:(__PMASK_P2_DIR__)

mov P2,a

mov r0,#__IO_MIRROR__+(0*4)+3 ; R:(__MODULE__) R:(__SLOTSIZE__)

mov a,[at]r0

xrl a,#BINNOT(0) ; R:(__PMASK_P3_POL__)

orl a,#255 ; R:(__PMASK_P3_DIR__)

mov P3,a

; ----------------------------------------------

; Function : CLOSECYCLE (ladrwork[00])

; ----------------------------------------------

mov __FIRSTCYCLE__,#0

mov r0,#__AREA_BOOL__

mov a,[at]r0

anl a,#0FEH

mov[at]r0,a

ljmp __Forever__

; ----------------------------------------------

; Function : BEGIN_INIT (ladrwork[00])

; ----------------------------------------------

cseg

__begin_init:

; ----------------------------------------------

; Function : CLOCK/INIT (ladrwork[00])

; ----------------------------------------------

extern _TICK_

izdata

CLOCK_CLK1:ds 3 ; R:(REFERENCE)

cseg

mov r0,#CLOCK_CLK1+0 ; R:(REFERENCE)

mov[at]r0,_TICK_+0

inc r0

mov[at]r0,#LOW(((1000000/1000)/TIMER_PERIOD)*2) ; R:(FREQUENCY)

; ----------------------------------------------

; Function : CLOSE_INIT (ladrwork[00])

; ----------------------------------------------

cseg

ret

; ----------------------------------------------

; Function : POSTINIT/BASEMODULE (ladrwork[00])

; ----------------------------------------------

cseg

__postinit:

; ----------------------------------------------

; Function : POSTINIT/BASEMODULE (modbus[00])

; ----------------------------------------------

cseg

; ----------------------------------------------

; Function : POSTINIT/BASEMODULE (panel[00])

; ----------------------------------------------

cseg

; ----------------------------------------------

; Function : CPOSTINIT (ladrwork[00])

; ----------------------------------------------

cseg

ret

; ----------------------------------------------

; Function : SHUTDOWN/BASEMODULE (ladrwork[00])

; ----------------------------------------------

cseg

public __ShutDown

__ShutDown:

; ----------------------------------------------

; Function : CSHUTDOWN (ladrwork[00])

; ----------------------------------------------

cseg

ret

; ----------------------------------------------

; Variable information table

; ----------------------------------------------

const

public __vit_begin

__vit_begin:

db 0FFH ; End of table

; ----------------------------------------------

; Function : ALLOCATEWORKAREA (ladrwork[00])

; ----------------------------------------------

dseg

__NODES__:

ds 1 ; R:(SIZE)

cseg

******************************************************

Questo è il file hex del mio codice:

:10000000C29012000CD29012000C80F479FF7AFF9B

:05001000DAFED9FA221E

:00000001FF

Questo è il file hex di ladderwork:

:1000000002006A020026000000000002003B00001F

:100010000000000200260000000000020026000090

:10002000000000020092327520C37521005389F050

:10003000438902758C00D2A9D28C22C0D0C0E0E5E1

:10004000204521600B1520E520B4FF121521800EFC

:100050007520C37521000522E52270020523D0E03A

:10006000D0D03212012612013322758110E5895455

:100070000F4420F5891200E6120027120063D2AF68

:1000800002014AC0E0E537B401FB753700D0E0F566

:100090009922C0E0C0D0D2D3C009E59854017007BE

:1000A000753701C2998017A936E524B41002800E75

:1000B00009B935027925E9F536E599F70524C2989D

:1000C000D009D0D0D0E032C000E52460FCA835C211

:1000D000AF152408B8350278258835E68000D2AF00

:1000E000D00022E52422C007C2AC7F207E002099E8

:1000F00004DEFBDFF7D007C299C298E589540F44AC

:1001000020F589438780758DFAD28E7598507425B5

:10011000F536F535752400C298C299753701D2AC11

:1001200022D0E0D0D032783F74236006FFE4F60896

:10013000DFFC229000007E007F00EE4F600BE4F0B9

:10014000A31FEFB4FF011E80F122753801783F76BE

:10015000011201BE1201C61201C8120458785BE5F3

:100160008064FFF6785CE59064FFF6785DE5A06456

:10017000FFF6785EE5B064FFF6785F7D14120459EF

:10018000785F12047D785C13E692E0F6E433785BE6

:10019000E664FF44FFF580785CE664FF44FEF5907A

:1001A000785DE664FF44FFF5A0785EE664FF44FFF7

:1001B000F5B0753800783FE654FEF602015D785FD1

:1001C000A6220876282222229004B3E493B4FF01E9

:1001D000227F0112031EEF5403B4011C7F0012039F

:1001E0001EBF58028018BF42028013BF570512027B

:1001F0004A800BBF442E8006B40229120226E582F3

:100200002414F582E43583F5830201CBB4580374DA

:100210000122BF4203740122B45703740222B44482

:1002200003740422E4227F00120308EF12020CF58B

:10023000F07F01120308A9077F0212031EAB07AA71

:10024000067F101203381202B522C0E074021203B6

:100250005A7F01120308A9077F0412031E8F058E1F

:100260000412043B74001203937F0C12031E7400EB

:100270001203D912043C70117F0812031E7400127D

:1002800003D912044C700280107F0212031EAA06CA

:10029000AB077F1012031E800E7F0212031EAA06F8

:1002A000AB0774001203B675F0021202B5740212A5

:1002B0000377D0E022740112035AC083C082C000C9

:1002C000C001C002C0077400AF011203FBD0077960

:1002D00007C007740012041BEFD0075460B4000677

:1002E000A803E7F68009B4200F8B828A83E7F00B1E

:1002F000EB70010A19D5F0D9D002D001D000D0821C

:10030000D083740112037722C083C082E5822FF567

:1003100082E43583F583E493FFD082D08322C083C7

:10032000C082E5822FF582E43583F583E493FFA351

:10033000E493FED082D08322C083C082E5822FF571

:1003400082E43583F583E493FFA3E493FEA3E4936F

:10035000FDA3E493FCD082D083228B3A8A3B893C74

:10036000F9D002D003E58129F581F53EC003C00232

:10037000AB3AAA3BA93C228B3A8A3B893CF9D00292

:10038000D003E581C399F581C003C002AB3AAA3B13

:10039000A93C228B3A8A3B893C883DF9D002D003A4

:1003A000E53E29F8A60718A606C003C002AB3AAA84

:1003B0003BA93CA83D228B3A8A3B893C883DF9D039

:1003C00002D003E53E29F88607188606C003C0025E

:1003D000AB3AAA3BA93CA83D228B3A8A3B893C8890

:1003E0003DF9D002D003E53E29F8E61886F0C003B7

:1003F000C002AB3AAA3BA93CA83D228B3A8A3B8972

:100400003C883DF9D002D003E53E29F8A607C00399

:10041000C002AB3AAA3BA93CA83D228B3A8A3B8951

:100420003C883DF9D002D003E53E29F88607C00399

:10043000C002AB3AAA3BA93CA83D2222C39FC5F00B

:100440009E400745F06003740122E422C39FC5F07B

:100450009E5003740122E422228601E522F6B501B2

:100460001108EDC313C3965004E408F62274010882

:10047000F6220816E6600280E9A60580E50808E68F

:100480002203E804070101003F0BB80BBF1009006D

:100490004B13881387200A005B2AF82B17010100F1

:1004A0005B32C832C91009005B3A983A98200A00BA

:0404B0005BFFFFFFF0

:00000001FF

[ffolks]

Rispondo ad Aleandro2008, circa il cosa simulare della vasta gamma HomePLC, che ribadisco, è geniale per come è stata pensata per la casa e per l'utilizzatore "smanettone".

La mia idea è quella di simulare il funzionamento a livello elettronico dei componenti I/O (master e slave) che abbiano al loro interno un core 8051.

Il presupposto è che tutta la comunicazione sia modbus rtu.

Pertanto nota la corrispondenza tra l'I/O fisico del core, l'I/O fisico del dispositivo e l'indirizzamento interno delle locazioni di memoria (per la parte modbus), sia relativamente semplice implementare una macro in ISIS che simuli identicamente il funzionamento di un modulo fisico di homeplc.

Poi connettere i vari moduli tra di loro, dotarli di inputs (pulsanti, sensori di temperatura, sensori di co2 etc) permetterà di avere le simulazioni ISIS VSM perfettamente corrispondenti a quello che sarà l'impianto una volta realizzato.

Il bello è che a questo punto si potrebbe tranquillamente scegliere con che linguaggio implementare le funzioni che si vogliono attribuire all'impianto di domotica che si vuole realizzare.

Fin qui funziona tutto in linea teorica, in pratica senza gli schemi dei vari componenti della famiglia HomePLC è praticamente impossibile, a meno di volersi studiare tutti i file .lst del compilatore per ogni funzione da lui implemetata.

Consentimi di esprimere una critica, non a te, ma al variegato mondo dei PLC-isti a tutti i costi, spero costruttiva, circa il parlare di automazione e linguaggi.

Contesto l'abbinamento del concetto di automazione con quello di PLC e dei suoi linguaggi standard.

Il PLC è solo una parte dell'automazione.

Poi, come quasi in tutte le vicende della vita, ci sono gli integralisti del PLC che pensano sia la cosa più avanzata, potente, precisa e funzionale per perseguire il concetto di automazione.

Poi ci sono quelli che pensano che un PLC S7 sia un cray in miniatura... (qui chiedo conferma a chi conosce bene l'HW ed il core dell'S7-300) e non sanno che è basato sul core 8051... e sparano sentenze sui microcontroller tipo pic e avr... che sono almeno tre generazioni avanti , per non parlare di uno stellaris, ora TI, 32 bit di mcu pronti all'uso...

Poi ci sono quelli che utilizzerebbero un PLC da xxxmigliaia di euro per gestire il livello dell'acqua della ciotola di Fido...

Ma in fondo, cosa è un plc ?

Se qualcuno volesse fare dell'automazione spinta (che so, un sistema di guida inerziale di un vettore, un sistema anticollisione aereo o automobilistico) non penso usi un PLC ma FPGA e verilog come linguaggio di programmazione, ed è automazione anche questa...

Se qualcuno volesse fare dell'automazione non spinta (che so, una macchina automatica del caffè, un regolatore di temperatura di un forno per saldature smd) non penso usi un PLC ma una scheda con una semplice mcu di una qualunque marca, ed è automazione anche questa...

Chiudo il discorso relativo ad automazione e PLC dicendo che in ambito industriale "standard" è appunto quasi uno standard usarlo, ma, il che, non impedisce di usare qualcosa che non si chiami plc ed ottenere di più.

Un saluto a tutti.

[del_user_56966]

Fin qui funziona tutto in linea teorica, in pratica senza gli schemi dei vari componenti della famiglia HomePLC è praticamente impossibile, a meno di volersi studiare tutti i file .lst del compilatore per ogni funzione da lui implemetata.

Complimenti per le tue capacità critiche, vedo che sei ben abituato a indagare a fondo sulle varie architetture

in questo caso pero ti ripeto che stai valutando uno solo degli aspetti dell'architettura HomePLC, se tu svolgi un

analisi di un sistema HomePLC basandoti solo sulla perte del core del PLC non riesci a comprendere l'intero parco delle

funzionalità da simulare, molte funzioni non risiedono nel compilato della parte PLC, era questo che intendevo quindi col fatto che

puoi simulare quello che svolge la logica programmata, ma non potresti comunque simulare quello che da questa non dipende...

qualcosa tipo quella che dici tu in realtà è già pronta, ci sono utilizzatori del sistema HomePLC che tramite ASCII oppure il

Modbus RTU si interfacciano al sistema da PLC come gli S7, sfruttando poi il simulatore integrato dell'ambiente per creare le varie

simulazioni...

Ma questo è solo uno dei vari modi di utilizzo, da questo approccio non si possono simulare appieno le funzioni più interessanti

che contraddistinguono questi prodotti da altri... anche se si possono sfruttare molti aspetti eleganti rispetto al sistema distribuito..

Rispetto al mondo dell'automazione, solo un appunto, quello che dici è vero ma la mia analisi si basa sulla percentuale d'uso

che si fa di un dato prodotto rispetto ad altri, quindi rispetto a questo sicuramente la maggior parte di utenti del mondo

dell'automazione non si producono prodotti in casa ma utilizzano quelli già pronti sul mercato, quindi PLC, CNC ecc..

è in questo caso che ritengo che la stragrande maggioranza degli utilizzatori utilizzi PLC, SoftPLC o prodotti equivalenti ma basati

sugli stessi concetti di base e sempre più standardizzati sulla programmazione IEC1131-3 indistintamente che poi si utilizzi solo

uno, due, oppure tutti e 5 i linguaggi di questa...

Modificato: 18 ottobre 2009 da Aleandro2008

[mshadow65]

Vediamo di fare un po' di luce su questa discussione ...

Prima di entrare in un dettaglio "squisitamente" tecnico e' opportuno

fare un breve cenno storico a riguardo di LadderWORK.

Il software LadderWORK e' nato alla luce di ben precisi requisiti

a) Permettere ai produttori di schede di controllo (Embedded PLC)

l'utilizzo di microprocessori e microcontrollori con ridotti

tagli di memoria e bassissimi costi

Permettere a CHIUNQUE di programmare dispositivi logici programmabili

attraverso l'utilizzo di un linguaggio grafico ed intuitivo. La clientela

(end user) a cui LadderWORK e' rivolto e' al 90% costituita da Installatori

ed elettricisti ed operatori di campo.

Il punto (a) ha condotto in breve tempo, mediante una attenta analisi di

mercato, che il microprocessore piu' conveniente e globalmente piu' utilizzato

(facciamo riferimento agli anni 1995-1996) era il core 8051

Il punto ( e' stato oggetto, in fase di analisi, di una lunga discussione.

All'inizio si era pensato di sviluppare un linguaggio Ad-Hoc. Negli stessi

anni pero' una nuova direttiva IEC/CEI si stava facendo largo nel mondo

dell'automazione: la IEC 61131-3.

Vien da se' che dopo aver studiato a lungo tale direttiva ne sono state

percepite le piu' importanti caratteristiche e da qui la scelta di sviluppare

LadderWORK sui fondamenti di tale normativa.

Una seconda parentesi si era aperta a riguardo di quali linguaggi sviluppare

all'interno della suite di sviluppo. Anche questa volta si era chiamato in

causa l'utilizzatore finale e da questa ultima seduta ne era scaturito che

sarebbero stati efficacemente utili i linguaggi come il LADDER e FBD

(Function Block Diagram).

Da questa analisi ne era scaturito il fatto che la tipologia di clientela

a cui il prodotto si stava rivolgendo non voleva ASSOLUTAMENTE avere a

che fare con linguaggi script, assembler, interrupts e simili problematiche.

Tutto quello che il software doveva fare era permettere al personale di

disegnare un diagramma e di premere un solo pulsante per svolgere

in modo semplificato le sessioni di compiling, downloading and run.

Sin dalle prime versioni di LadderWORK (Uscite nel Settembre 1997 sotto

sistema operativo Windows 3.1) l'interfaccia (IDE) ha basato il suo aspetto

rispettando tale prerogativa nativa.

A questo punto ......

Chiusa la parentesi storica possiamo ritornare alla discussione tecnica.

Partiamo dalla seguente assunzione:

[-] Semplicita' di utilizzo, potenza del linguaggio ed astrazione non

vanno di pari passo con prestazioni ed efficenza.

Cosa significa questo?

L'esempio che e' stato fatto a riguardo del programma per il led lampeggiante

apre un vivaio di osservazioni

Come puoi osservare dal compilato di LadderWORK vi sono "Infrastrutture" base

che devono obbligatoriamente essere incluse per poter "generalizzare"

l'hardware su cui il compilatore sta operando. Faccio riferimento per esempio

ai blocchi SOC/EOC e similari. Se andiamo ad osservare nel dettaglio il codice

generato da LW si puo' facilemente intuire che il cuore del processo e'

racchiuso all'interno del seguente frammento:

; ----------------------------------------------

; Function : CLOCK/CLOCK (ladrwork[00])

; ----------------------------------------------

extern __clock

mov r0,#CLOCK_CLK1 ; R:(REFERENCE)

mov r5,#LOW((1000000/1000)/TIMER_PERIOD) ; R:(FREQUENCY)

lcall __clock

; ----------------------------------------------

; Function : CLOCK/OUT (ladrwork[00])

; ----------------------------------------------

extern __clock_out

mov r0,#CLOCK_CLK1 ; R:(REFERENCE)

lcall __clock_out

; ----------------------------------------------

; Function : OUTPUT/B (iomem[02])

; ----------------------------------------------

cseg

mov r0,#__IO_MIRROR__+(0*4)+1 ; R:(__ADRLEVEL1__) R:(__SLOTSIZE__) R:(__ADRLEVEL2__)

rrc a

mov a,[at]r0

mov ACC.0,c ; R:(__ADRLEVEL3__)

mov[at]r0,a

clr a

rlc a

Ovvero ...

Il compilatore utilizza una "CLASSE" (A questo punto ci si potrebbe divertire

divagango con altre definizioni tipo "oggetto" ed "oop") denominata CLOCk.

Il codice di gestione di tale classe e' unico per tutte le istanze del

componente CLOCK che andrai ad utilizzare nel diagramma. Questo significa

che l'overcharging di libreria diventera' sempre piu' sottile mano a mano

che il numero di componenti CLOCK aumenteranno nel diagramma.

Altra caratteristica importante e' che il componente CLOCK rispetta,

come ovviamente reso necessario in un sistema Real Time, la sincronizzazione

con il resto del sistema per la generazione delle frequenze programmate

nelle proprieta'. Questo significa che LadderWORK e' in grado di supportare

un numero indefinito di componenti di temporizzazione gestendo

separatamente e parallelamente tutte le frequenze e i time-delay

programmati. Solo la potenza di calcolo del processore puo' porre un limite

sul numero di componenti piazzabili.

L'esempio che e' stato fatto riporta solo una semplice routine di delay che

non permette in alcun modo di sapere a priori il ritardo che suddetta funzione

generera'. Solo dopo una particolare calibrazione dei coefficenti si potra'

avere il ritardo desiderato. Ma c'e' un problema di fondo ... che cosa accade

se cambio la frequenza oppure l'hardware sul quale il codice sta girando?

Ovviamente il codice non avra' piu' lo stesso comportamento.

Con LadderWORK tutte le tempistiche sono riferite ad un unico parametro

configurabile: La SYSTEM CLOCK ovvero la frequenza operativa del

processore.

Un'altro quesito:

E se io volessi far lampeggiare dieci led con frequenze completamente

diverse? Il codice "cablato" in assembler andrebbe completamente rivisitato

Dovresti perlomeno introdurre una gestione piu' intelligente delle temporizzazioni

iniziare ad introdurre l'utilizzo dei timers e degli interrupts e molti altri

elementi ...

L'utente di LadderWORK invece cosa fa? Semplicemente copia ed incolla altri 9

blocchi e configura le proprieta' di ognuno di essi. Una sessione di questo

tipo puo' richiedere al massimo 2 minuti .... in assembler? Quanto tempo

richiederebbe?

Ma a questo punto ritorniamo alla domanda base: Ma veramente la MicroSHADOW

potrebbe fare programmare i suoi clienti utilizzando istruzioni del tipo

mov a,r3

mov a,#1

??

ASSOLUTAMENTE NO! QUESTO NON E' POSSIBILE! MicroSHADOW CONOSCE LA PROPRIA

CLIENTELA E LA CLIENTELA DOMINA LE DECISIONI DI MicroSHADOW

Faccio un'ulteriore divagazione ..... il programmino che hai pubblicato

e' sicuramente indice di passione verso il mondo dei microcontrollori.

E' veramente grandioso che la gente si appassioni ed utilizzi questi

fantastici strumenti. Penso che tu abbia capito che con molta probabilita'

condividiamo una passione comune .... io utilizzo assembler quotidianamente ....

e' il mio lavoro quotidiano.

Ma molte persone pero' hanno difficolta' nella scrittura di applicazioni

con l'utilizzo di questi linguaggi ... ne renderai atto ..... a volte

puo' essere un tantino ostico :-)

Ma continuiamo un attimino nell'analisi del codice di LadderWORK. Come

si puo' intuire dai frammenti di codice generato si possono distintamente

notare che vi sone delle porzioni di codice, non attivate nell'esempio in questione,

che fanno parte di infrastrutture "discretamente" complesse quali la gestione

del protocollo MODBUS e dell'interfaccia uomo macchina (HMI). Attivando

queste funzionalita'si puo' disporre in modo automatico e gratuito di librerie

atte alla gestione delle funzioni suddette.

E' abbastanza chiaro che all'interno di una piccola chiamata a libreria

vi sia in profondita' un mondo molto ma molto piu' complesso a livello

di funzionalita'

Quanto tempo occorre per scrivere in linguaggio assembler un intero protocollo MODBUS?

Con LadderWORK tutto questo viene semplicemente attivato con una Check-Box in una

dialog ... la stessa cosa per il supporto HMI ....

Penso che sia abbastanza chiara la differenza tra il far lampeggiare un led in

assembler ed utilizzare LadderWORK.

LadderWORK ti mette a disposizione una libreria di circa 70 componenti ready-to-use.

Non serve programmare ... basta utilizzarli !!! :-)

Ti ripeto ... apprezzo profondamente la gente che riflette la propria

passione su queste fantastiche tecnologie e spero di poter comunque

trovare l'occasione per un confronto meno "telematico" e piu' "diretto" con

persone come voi

Come avrai capito io con MicroSHADOW ho molto a che fare ... in pratica

ci sono dentro fino al collo :-)

Vorrei per ultima cosa fare una precisazione sulle versioni commercializzate

nel mondo.

LadderWORK viene venduto in "Bundle" con i prodotti dei vari clienti.

Il marchio LadderWORK® e' utilizzato solo per le versioni generiche 8051

ma lo stesso core viene venduto sotto altri nomi e marchi.

LadderWORK 8051 ha trovato terreno fertile in paesi come la Cina, L'india

,Korea e l'Est europeo

Esistono versioni specializzate di LadderWORK per applicazioni particoari

quali il controllo assi e CNC. Versioni ultra-particolari di LadderWORK

sono utilizzate comunque nei campi piu' particolari.

In questo casi il processore target non e' un 8051 ma bensi' vengono

utilizzati core quali SH e PowerPC. Ovviamente i costi dell'hardware

sono molto diversi.

La MicroSHADOW sta attivamente procedendo nello sviluppo di altre

versioni .... ma questo per ora e' assolutamente *TOP SECRET*

PS: Conosciamo benissimo la nostra concorrenza ed analizziamo

ogni prodotto sul mercato. Il prodotto freeware che e' stato

menzionato ovviamente non puo' essere paragonato a livello

di prestazioni e di supporto .... e' poco piu' di

un giocattolo

In Fede

Gianluca

[del_user_56966]

; ----------------------------------------------

; Function : CLOCK/CLOCK (ladrwork[00])

; ----------------------------------------------

extern __clock

mov r0,#CLOCK_CLK1 ; R:(REFERENCE)

mov r5,#LOW((1000000/1000)/TIMER_PERIOD) ; R:(FREQUENCY)

lcall __clock

; ----------------------------------------------

; Function : CLOCK/OUT (ladrwork[00])

; ----------------------------------------------

extern __clock_out

mov r0,#CLOCK_CLK1 ; R:(REFERENCE)

lcall __clock_out

; ----------------------------------------------

; Function : OUTPUT/B (iomem[02])

; ----------------------------------------------

cseg

mov r0,#__IO_MIRROR__+(0*4)+1 ; R:(__ADRLEVEL1__) R:(__SLOTSIZE__) R:(__ADRLEVEL2__)

rrc a

mov a,[at]r0

mov ACC.0,c ; R:(__ADRLEVEL3__)

mov[at]r0,a

clr a

rlc a

In pratica in LadderHome questo è equivalente all'uso di un flag di sistema che permette di scegliere una base dei tempi

tra 0.1, 0.2, 0.5, 1, 2 secondi per poi passare alla librerie clock che permette di scegliere anche tempi intermedi tra questi...

ovvero di base tutto il codice di sopra si può esprimere con questo simbolo ladder ----||---- e il giusto indirizzo IEC...

tanto semplice quanto Geniale no?

[del_user_56966]

Noto con piacere che anche per gli HomePLC, come nei migliori sistemi professionali

siamo arrivati all'analisi di funzioni di bassissimo livello.....

che indistintamente dal risultato del confronto sono sempre valide, anche se poi quello che viene richiesto non è tanto

di sapere come lampeggia un led in assembler, ma all'utente penso interessi più che questo sia di immediata realizzazione e che il risultato del

programma una volta eseguito sul Bus mantenga caratteristiche deterministiche,

infatti non ci scordiamo una cosa, nessuno sta osservando un piccolo particolare,

voi state discutendo di un programma sviluppato per un classico PLC, (anche se fosse sviluppato con LW per core 8051) mentre

un HomePLC ha una grossa differenza lavora completamente in distribuito,

voi state discutendo di soluzioni più affini ai PLC con controllo degli I/O parallelo, mentre gli HomePLC gestiscono

il controllo degli I/O completamente su Bus seriale, quindi in questo caso tempi e struttura real-time è completamente differente,

diciamo che gestire un prodotto parallelo è molto più semplice sia da capire che da sviluppare rispetto a un sistema equivalente ma completamente

implementato su Bus ...

Ovvero far lampeggiare un led su un piedino della CPU non è affatto equivalente al fare lo stesso lavoro in un punto qualsiasi dell'impianto tramite un Bus

dove in contemporanea lavora, diagnostica, eventi, sensori, I/O generici, telecontrollo ecc..

forse è qui che le performance di sistema danno il meglio di loro!

Come dicevo prima per fare un analisi si deve valutare l'intero sistema e non solo una parte di questo...

Modificato: 18 ottobre 2009 da Aleandro2008

[ffolks]

Come ho già detto, ladderwork il suo lavoro lo fa, ma questo non significa che mi debba piacere, in quanto detesto il ladder.

Che disegnare in ladder un circuito per automatizzare (domotizzare) delle funzioni sia semplice è fuor di dubbio.

Ma per altri potrebbe essere più semplice o appetibile o gradito voler gestire homePLC con un altro linguaggio e l'apertura del sistema a basso livello potrebbe rappresentare per il produttore HomePLC un must ed un probabile vantaggio competitivo.

Ricordate la vicenda Apple vs PC? Computer fantastici, sistema operativo rivoluzionario, icone mouse, semplicità di utilizzo ai massimi livelli; sull'altro fronte scatolotti in lamiera, interfaccia a caratteri, osticità d'uso.

Apple rischiò di fallire ed il Pc con i suoi vari cloni divenne l'incostrato dominatore del mercato.

Direte, ma Apple costava un'accidente rispetto ad un PC. Ma il costo non fu la discrimante.

Apple mantenne il sistema chiuso mentre di un PC potevi conoscere il minimo dettaglio di funzionamento, anche a livello di circuiti elettronici, quindi decine di nuovi compilatori, drivers per le più svariate periferiche ed interfaccie etc...

Capita la lezione apple rese il sistema aperto , evitò di un soffio il fallimento ed oggi è quella che è!

Con un occhio rivolto al di là dell'oceano vedo una cosa chiamata LonWorks che cresce cresce cresce... con quello ad oriente tante soluzioni ad hoc chiuse e proprietarie, e non credo che seguire solo lo standard IEC 61131-3 o KNX sia la soluzione per la domotica e la building automation.

Per la cronaca, il vostro contatore elettronico ENEL è già un nodo lonworks con il suo bel chip famiglia 5000.

[del_user_56966]

Ma per altri potrebbe essere più semplice o appetibile o gradito voler gestire homePLC con un altro linguaggio e l'apertura del sistema a basso livello potrebbe rappresentare per il produttore HomePLC un must ed un probabile vantaggio competitivo.

e chi ti dice che non sia già previsto, in fondo per il momento il sistema è in pieno sviluppo,

e ogni tecnologia non sembra essere mai scartata a priori... sono sicuro che se il mercato, come dici tu lo richiederà vedremo anche la versione LON e

non solo quella...

[ffolks]

Lo hai detto tu adesso, visto che nessuno lo ha detto prima della mia affermazione.

Il che mi porta a pensare che tu faccia parte del pool di sviluppo di HomePLC, e quindi a domandarti: perchè non rilasciate l'elenco completo degli indirizzamenti modbus rtu dei devices in un pdf scaricabile dal forum invece che nel manuale di ladderhome?

Se la via intrappresa da Homeplc è questa, allora evviva... ognuno potrà svilupparsi il proprio sistema nei modi che più gli aggradano, e perchè no, magare iniziare a progettarsi anche dell'hw ad hoc (schedine zigbee, slaves che facciano da bridge con i soliti noti, e si, questo sarebbe un colpaccio ...).

Un grazie ad Aleandro, con cui è un piacere confrontarsi.

[del_user_56966]

perchè non rilasciate l'elenco completo degli indirizzamenti modbus rtu dei devices in un pdf scaricabile dal forum invece che nel manuale di ladderhome?

è già stato rilasciato, certo se lo cerchi su internet non lo trovi ma se disponi di un HomePLC oppure un Master I/O lo puoi richiedere tranquillamente, anche

perché in caso contrario non ti serve a nulla...

se ti può interessare sono molti i progetti aperti su questo ambito, guarda questo per esempio...LINK

altri sono su base linux ecc.. come vedi la tua idea è già realizzabile e su qualunque piattaforma, e le performance rimangono altissime in qualsiasi

soluzione, c'è sentore anche si soluzioni ancora più spinte ma sui tempi al momento non so darti info aggiuntive...

Modificato: 18 ottobre 2009 da Aleandro2008

[ffolks]

Supponiamo che il master I/O lo voglia realizzare io usando un AVR XMega e che come slave optassi per 5 magnifici ragnetti HomePLC 4 ingressi ed un paio di ragnetti analogica 0-10V.

Chiaramente non voglio usare ladder, proprio non ci riesco, sono allergico ...

Come faccio a dialogare con i ragnetti HomePLC ?

No master HomePLC no party?

Un grazie in anticipo.

[del_user_56966]

Chiaramente non voglio usare ladder, proprio non ci riesco, sono allergico ...

Come faccio a dialogare con i ragnetti HomePLC

Non devi utilizzare necessariamente un HomePLC, ma un dispositivo chiamato Master I/O

che in pratica è una periferica già utilizzabile visto che dispone di 4 ingressi e 4 uscite a relè,

questo ti permette di comunicare in real time

con ben 28 dispositivi digitali di I/O (Ragnetti, moduli da 4+4 oppure 16+16 I/O ecc..)

e 18 registri per dispositivi di I/O come transponder RFID, Luxmetri, Dimmer ecc..

La gestione I/O di tutti questi dispositivi può avvenire con più protocolli, quindi niente Ladder o altro linguaggio

e come controller si può utilizzare qualsiasi dispositivo che sia programmabile in qualsiasi linguaggio ottenendo

di base gli stessi tempi di controllo....

Questa soluzione è già ampiamente utilizzata con PLC Industriali, PC-Panel, Embedded di vario tipo,

e Controllori Domotici di altre soluzioni....

Modificato: 19 ottobre 2009 da Aleandro2008

[ffolks]

Grazie per la spiegazione, ma il quesito a cui desideravo ricevere risposta era : i ragnetti homeplc come faccio ad interrogarli senza passare per un master i/o ? Ovvero che telegramma modbus devo inviare e che risposta devo attendermi?

[del_user_56966]

Non penso che al momento siano rilasciati per essere gestibili singolarmente,

il Modbus RTU è utilizzato per l'interrogazione di HomePLC, Master I/O, DMX512 e altri moduli discreti quando interrogati direttamente da un

host che utilizzi il protocollo Modbus RTU in versione Master...

Non è necessario accedere direttamente da un Host modbus a un dispositivo dopo il master I/O in quanto questo lavoro è già ottimizzato dal master stesso,

se tu volessi fare il suo lavoro non otterresti mai lo stesso risultato in fatto di performance anzi l'applicazione diventerebbe estremamente lenta, quindi

l'uso senza master in questo tipo di soluzione può dare solo problemi e non porta alcun vantaggio!

[ffolks]

Mi piacerebbe capire come possa rallentare l'intero sistema l'interrogazione fatta in modbus ad un dispositivo modbus (ragnetto) da un master che non sia un master I/O della homePLC.

Sempre di lettura/scrittura di una locazione (registro) trattasi.

Nell'immagine del sistema di connessione proposta da HomePLC (vedi 'forum novità dalle aziende') i ragnetti sono connessi in RS485.

Ritenevo che fosse tutto gestibile in modbus.

Pazienza, evidentemente il sistema è "open" solo a livello di HomePLC (inteso come device fisico) e tutto quello che sta sotto (ragnetti, dimmers, termoregolazione, controllo accessi...) è si in modbus, ma con protocollo chiuso e proprietario.