Flags for "4 analog output extension"



  • Hello,
    we 've studied the RPiDrv-manual carefully. At the moment there is no table of flags for the "4x analog output extension" included. Also we couldn't find a suitable mdl-file (only the relay-extension is available).

    Because the flags for the UniPi internal AO (1x @GPIO18) are "UNP__AO" (0-10V) or "UNP__AO1X" (0-1023 Pwm) it is not clear how they are changing for the AO-extension.

    for example:
    "UNP__AO_A33" would link to the I2C-address but not to no. of AO-slot (1…4 or 0...3 possible). Same problem for the other 12 PWM-slots. If the slot-no. is used in the flag than it might be a problem with the "UNP__AO1X"-name.

    Can you give the necessary information, please.
    with best regards
    iot

    ps
    There is a little mistake in the manual at page 15, table, last column. Address 32 is covered by RTC, so 32 should be 33 like correctly showed in column "string".



  • Hello,
    we 've studied the RPiDrv-manual carefully. At the moment there is no table of flags for the "4x analog output extension" included. Also we couldn't find a suitable mdl-file (only the relay-extension is available).

    Because the flags for the UniPi internal AO (1x @GPIO18) are "UNP__AO" (0-10V) or "UNP__AO1X" (0-1023 Pwm) it is not clear how they are changing for the AO-extension.

    for example:
    "UNP__AO_A33" would link to the I2C-address but not to no. of AO-slot (1…4 or 0...3 possible). Same problem for the other 12 PWM-slots. If the slot-no. is used in the flag than it might be a problem with the "UNP__AO1X"-name.

    Can you give the necessary information, please.
    with best regards
    iot

    ps
    There is a little mistake in the manual at page 15, table, last column. Address 32 is covered by RTC, so 32 should be 33 like correctly showed in column "string".



  • Hi,
    at the moment it is possible to control the EMO-AO4/12 via the REXLANG programmable function block. Native support of this extension board will be added in future releases of the REX Control System. I'll prepare an example for you.

    And thanks for reading our manuals thoroughly, we'll fix that!

    Jaroslav



  • Hello Jaroslav,
    thanks for your answers.

    If the native Rex-support of EMO AO4/12 is integrated within the next 2 month it would be no problem. Then no special solution would be necessary. In meantime we can program Rex for the much more used UniPi-sensors/actors (1-wire, 4 relays, 1 AO (pwm Gpio18), 6 inputs). After that we add the hopefully integrated 4/12_AO-Extension with Rex-update.

    There is another thing we are thinking about. The RexCore @RPi is licenced with the used hardware. We plan to use UniPi v1.1 + EMO_AO4/12. Also the new PiDrive for SSD-Drive shall be used. The PiDrive comes later (also the 4/12 AO-ext. due to missing Rex-drv.) so there is the question if licencing without SSD and AO-ext. at the beginning requires a new key in the end (with SSD + AO)?
    We read that SDCard is also used for hardware-ID/license key. If users only work with SDCard and it corrupts they would need a new key, isn't it?

    For our purpose we need system as stable as possible - that's why we choosed PiDrive or USB-Mini-HDD for Linux. A backup-system (another RPi with another SDCard) would be impossible with only 1 license-key, wouldn't it?

    with best regards
    iot



  • OK, thanks for the time frame.

    I'll start a new thread about the licensing.

    Jaroslav



  • I just pushed an example on using the EMO-AO4/12 expansion board to our GitHub repository.

    See https://github.com/rexcontrols/REXexamp ... es/EMO-AO4
    or download the repo as a zip file https://github.com/rexcontrols/REXexamples/archive/master.zip

    Hope this helps. Let me know.

    Jaroslav



  • Thank you Jaroslav, we will have a try.
    with best regards
    iot