[Giulio]

Chiarissimo…
Una volta compreso il problema ci si puo’  organizzare in attesa di eventuali improvements.
Grazie della, come sempre, precisa risposta.

[Giulio]

Il problema su FTP lo dà su tutti i client che ho provato… su pc filezilla, command line DOS, browser WEB. su Android altri tre o quattro che non ricordo…

Su PC, comunque, dopo qualche tentativo e time-out Filezilla recupera e trasferisce i file, mentre su Android l’unico che è andato bene è il plugin di Total Commander.

Comunque ho visto il post cui facevi riferimento e probabilmente, come dicevi, è un problema di time-out ma l’impressione è come se il questo time-out  fosse notevolmente più breve  di 30″. Cmq come dicevo con Total Commander su Android e il suo plugin FTP riesco a fare quello che occorre…

[Giulio]

Ok, ho aggiornato e le pagine si vedono anche su Android. Resta l’instabilità di FTP che non trasferisce subito i file in Storage.
Il nuovo compilatore però mi ha dato errore su quest linea di codice che prima andava tranquillamente…

PrintFResult:=SysVarfprintf(FP, ‘%s$r$n’,STRING_TYPE , ‘———————————‘);

L’errore è ScriveLog(89) – error A4107:  STRING_TO_UINT => Function not found

Inoltre, diversamente da prima, ha generato il codice eseguibile nonostante l’errore, non mi ero accorto della segnalazione e naturalmente a run time si è bloccato tutto…

Ho risolto definendo una costante stringa e passando alla funzione il puntatore, ma sarei curioso di sapere a cosa sono dovuti questi cambiamenti… magari schivo altri problemi…

….sempre mille grazie x la collaborazione !

[Giulio]

Al momento funziona con tutti i browser da Windows ma da nessuno su Android ! Anche il server FTP mi dà qualche problema, si connette correttamente ma non riesce sempre a scaricare i file quando l’applicazione è in running. Con l’applicazione in halt va sempre bene.

Sul target ho la verione SFW184A930 ho visto che l’ultima è la 60… è necessario fare l’upgrade a quella o alle successive che però vedo indicate essere XTarget_12 ? Lo SlimLine su cui stò lavorando è Mps053_XTarget_11_0.

Non mi è chiaro cosa si intende per “I prodotti con questo Fw sono visti da LogicLab come XTarget 12”

Nessun problema con vecchie applicazioni ? Considera che tutte le applicazioni che abbiamo sviluppato si interfacciano su bus I2C con  schede di acquisizione e di interfaccia custom.

[Giulio]

Io ho interrogato quegli indirizzi con altri emulatori e client Modbus anche da devices Android… leggo correttamente i dati dalla memoria DB100 ma vedo tutti zero nei 100-105 e 150 (e limitrofi…) Non avevo  provato  con Toolly, che, in effetti,  e’ piu’ “diretto” e controllabile… con Toolly in effetti si  legge correttamente.

Forse c’e’ qualche problema di indirizzamento sugli altri client che mi e’ sfuggito…

[Giulio]

Stò facendo una serie di test con un modulo lettore RFID SL018 Mifare Reader/Writer connesso sul bus I2C, stò utilizzando la funzione SysI2CWrRd da un programma LD impostando i comandi in array di costanti e trasmettendoli ad modulo. Il tutto funziona correttamente, i comandi (lettura dell UID, lettura della relase del FW, login semplice etc.) funzionano in scrittura e lettura; nei buffer vedo valori corretti che evolvono esattamente come mi aspetto, ma la funzione SysI2CWrRd non ritorna mai esito positivo.

Ho utilizzato alimentazione, GND ed i segnali due segnali SCL ed SDA. Non utilizzo il segnale RDY (e non ne ho fatto il pull-up). Il cavetto è lungo 25-30cm, predisposto per un altro modulo che dovrò collegare. Ho fatto diverse prove assegnando il programma alla task Fast, Slow e Back senza notare differenze.

[Giulio]

Dal manuale hardware (che non avevo ancora visto) leggo, par. 2.1, che non è possibile inserire sul bus I2C Slimline delle periferiche standard I2C!  In realtà il paragrafo non mi risulta chiarissimo: Questo vuol dire che non è possibile utilizzare i moduli che stavo valutando che presentano, appunto, una interfaccia I2C “standard” con il loro indirizzo e un set di comandi per la gestione ? O forse il problema è solo relativo alla gestione degli  I/O ? Tra l’altro ho visto delle vostre applicazioni (gestione del display alfanumerico e dello step motor)  che mi sembra utilizzino hardware ‘standard’…

Contavo  di utilizzare proprio un PIO I2C per comandare una semplice schedina con display a 7 segmenti ma davo per scontato l’immediato interfacciamento del modulo lettore RFID sul bus. Per la prima realizzazione, tutto “vicino”, non prevedevo neanche di inserire particolari reti di pull up o altre protezioni…

Il mio modulo, come dicevo, ha un I/F I2C standard, e un set di comandi formati da PDU di lunghezza variabile che consentono di leggere e scrivere i settori dei TAG RFID eventualmente connessi. Sono dotati di autorilevamento di TAG che utilizzerei tramite un ingresso standard della CPU per dare il via alla gestione. Allego manuale del SL018 Mifare Reader/Writer che è la periferica che intendo usare.

Non è stato possibile utilizzare l’HID, cosa che mi avrebbe assai semplificato la vita,  perchè il cliente vuole salvaguardare i 5000 badge già esistenti che sono risultati essere MIFARE 1 a 13,5 Mhz.

Riassumendo,  sul BUS Slimline dovrebbero convivere: da 1 a tre moduli di I/O “standard”, il lettore/scrittore RFID ed un semplice display… ce la possiamo fare ? Sempre grazie per l’attenzione e le concrete risposte !

[Giulio]

Davvero un aiuto prezioso… sono pochi giorni che sto utilizzando l’ambiente e andando di fretta, con tanta roba, temo sempre sfugga qualcosa di grosso ! Apprezzo davvero molto il tuo contributo.

In altre prove che ho fatto ho gestito meglio i dettagli di contorno ma qui mi sono incastrato in mille prove sul codice e quello che tu hai è solo uno dei vari tentativi (come ti accennavo ho usato variabili globali, locali, array, assegnazioni dappertutto… porcherie di ogni genere per aggirare il problema che pensavo potesse essere di indirizzamento).

Quindi, in conclusione, mi sembra di capire che il problema è legato  anche in questo caso alla necessità di  lettura del fronte invece che semplicemente dello stato dell’I/O…. però nel programma ladder il comportamento era opposto: li’ ad ogni ciclo veniva trasmessa la stringa sino al rempimento del buffer, qui veniva ignorato tutto ! Hai idea del perchè di questa differenza ?

[Giulio]

Forse sono stato troppo prolisso…la cosa non è complessa ! io ho usato una semplice variabile mappata sull’I/O come nel tuo esempio… poi,  visto che non funzionava, ho provato di tutto,  tra cui il mappaggio su un array fatto tramite un programma LD (4 network, su ciascuno un contatto che valorizzava una posizione dell’array).

Dimentica l’array… Il problema resta semplice e sicuramente legato a qualche mio errore basilare e concettuale: ho una variabile “PremutoTasto” collegata all’ingresso 1 del modulo CPU e la testo in AND alla SocketConnect ; Quando premo il tasto, nella finestra di watch si vede la variabile passare a TRUE,  ma il programma continua a considerarla FALSE…

Controprova: Definisco la variabile inizializzata a TRUE; il primo giro va bene, viene riconosciuta e la stringa parte, poi, tornata FALSE,  non viene più letta correttamente dal programma (mentre in watch window evolve correttamente).

[Giulio]

No, è lo stesso programma funzionante in LD, sempre nell’ambito di prove di comunicazione. Era nel task di background ma ho provato anche ad inserirlo in altri task. Accetta connessioni TCP  su un socket diverso dal programma di prima (e funziona, si connette)  e, se connesso, su pressione di un tasto invia una stringa.

Ho provato usando la stessa variabile globale usata per il programam LD, un’altra variabile, una variabile locale, un array in cui mappavo i 4 ingressi con un programma LD…. nella finestra watch vedo sempre la variabile diventare TRUE quando attivo l’ingresso  ma il programma continua a girare come se fosse FALSE. Se inizializzo la variabile a TRUE, funziona al primo giro, poi quando uso l’ingresso non va più (ma nel watch è sempre tutto OK). Ho ipotizzato problemi di sintassi mettendo la variabile dentro e fuori parentesi ma continua ad ignorarmi ! 

Riassumo, per chiarezza: sul PLC nel task di background girano due programmi, uno scritto in LD che ascolta sulla porta 1111 e un altro scritto in ST che ascolta sulla porta 2000. In un tentativo che ho fatto c’è un terzo programma in ladder che mappa i 4 ingressi della CPU in un array letto dal programma ST. Questo programma era stato messo nel task SLOW.

Il tuo programma di esempio, naturalmente, funziona… il che mi fa pensare che nel mio ci sia ancora qualche problema “esistenziale” legato ad interazioni con altre funzionalità…

[Giulio]

OK…chiaro !  Lo dicevo che mi sfuggiva qualcosa di banalmente fondamentale ! Ho utilizzato il contatto -|p|- e funziona tutto normalmente !

Qualcosa del genere (banali errori fondamentali)  mi sta succedendo con il codice ST: le variabili collegate ad ingressi non vengono “sentite” dal programma. Nella finestra watch le vedo “muoversi” correttamente ma il programma le legge sempre “FALSE” e si comporta di conseguenza (mi ignora !).

Tra l’altro non ho visto esempi funzionanti di gestione di ingressi logici letti con programmi ST. Puoi darmi qualche spunto anche qui ?

[Giulio]

La mia perplessità era appunto sulla differenza di comportamento della SysVarfprintf che avevo osservato tra il linguaggio LD e ST. Considera che nelle prove che ho fatto l’esecuzione della funzione non era ‘libero’, ma condizionato alla effettiva connessione di un client (SysSktListen.Connect ) in AND ad un ingresso della CPU…

Con client connesso premevo il tasto, partiva la stringa…. in effetti alla pressione del tasto la stringa parte ma viene trasmessa N volte. Per la precisione, osservando il watch delle variabili della printf ho notato che questa non trasmette 100 caratteri (valore del buffer) ma i 10 previsti… solo che sembra venga richiamata N volte ! ….

Temo mi sfugga qualcosa di banalmente importante !

[Autore]

Post