-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 08.10.2012 16:42, schrieb Thomas Bitsky, Jr.: > What you're proposing would be a mistake. The value coming back is > the value of that object in the field. You send out a value, the > slave reads it, then puts in the value that is actually there. If > it just took your value and never did anything with it, you'd be > blind to what is going on out in the field. The fieldbus isn't your > personal memory buffer; it's feedback of what is going on in the > real world.
That's not true. A slave will *never* change RxPDO-only data in the frame. For pure RxPDOs (master -> slave) you will receive exactly the data you were sending. An exception is, if the PDOs are configured to overlap each other (implemented in the default branch). In this case the slave will read the RxPDOs from the frame and after that write its TxPDOs to the same place, to save bandwidth. But this is not the point here, as I understood. The *one and only* method to check if the slave accepted the data from the frame (and/or wrote valid data into the frame) is the working counter, which you can access via ecrt_domain_state()! > Example: I turn on an output to an EL2004 output slave. When that > value comes back to me, that bit is either still on, which means > that the slave turned it on in the real world, or it's off, which > means that the slave didn't turn on the output for some reason. > But, now I know that and can do something about it. If it just left > the value at 1, I'd have no idea that it hadn't turned on and my > process would continue on unaware. This is definitely wrong. - -- Viele Grüße, Florian Pose - ------------------------------------------------------------------------ Dipl.-Ing. (FH) Florian Pose [email protected] Tel.: +49 201 / 36014-13 Ingenieurgemeinschaft IgH Gesellschaft für Ingenieurleistungen mbH Heinz-Bäcker-Str. 34 D-45356 Essen Amtsgericht Essen HRB 11500 USt-Id.-Nr.: DE 174 626 722 Geschäftsführung: - - Dr.-Ing. T. Finke, - - Dr.-Ing. W. Hagemeister Tel.: +49 201 / 360-14-0 http://www.igh-essen.com GnuPG key: CCA047CC 2007-12-18 [expires: 2012-12-16] Fingerprint: 0081 4005 FE9F 73FF 4BDA A409 0011 4E20 CCA0 47CC - ------------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB0Cg4ACgkQABFOIMygR8w1+ACgvPuEzOQ6rSQNbYQRpiw6eo8B CrIAoMPGVU7q26P2F9oTvtZqyO1IsW53 =uQjd -----END PGP SIGNATURE----- _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
