arduino-libraries / arduino_machinecontrol

[Deprecated] Portenta Machine Control Library for Arduino

Warning

This library is deprecated and no longer actively maintained.

We recommend transitioning to the Arduino_PortentaMachineControl library for ongoing support, new features and contributions. If you need assistance with migration, refer to the migration guide.

Please note that the examples provided with this library are not compatible with the new library.

Arduino Library for the Portenta Machine Control

The Portenta Machine Control enhances existing products with minimal effort, allowing companies to implement a standard platform across different equipment models. It is now easy to create an infrastructure of interconnected machines, which can be controlled onsite or via the cloud when needed; moreover, human-machine interaction can be further enahnced via mobile apps thanks to BLE connectivity.

For more information about this library please visit us at https://www.arduino.cc/reference/en/libraries/arduino_machinecontrol/ For more information about this product: https://www.arduino.cc/pro/hardware/product/portenta-machine-control

License

Copyright (c) 2021 Arduino SA. All rights reserved.

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

arduino_machinecontrol's Issues

DIGITAL_OUT and DIGITAL_PROGRAMMABLE has different latch_retry in V3.0

Now in V3.0 DIGITAL_OUT has latch_retry attached to PB2
Now in V3.0 DIGITAL_PROGRAMMABLE has latch_retry to PH14

More USB host examples

Hello,
I was wondering if you could expand the current USB host example or add more examples. In particular, I'm looking into using the USB Type-A port on the Portenta Machine Control to access a text file on a USB drive containing the configuration for my device, which is probably the most common use case for a USB port on an industrial control unit. I can't really find a lot of information online on how to do that, not even the Portenta Breakout library has examples on how to use the USB Type-A port.
In the future, I would suggest adding the possibility of updating the firmware using a USB drive, however I don't need it right now.
Regards,
Marco Cipriani

Analog IN .set4_24mA

Change to .set4_20mA

Which is the latest official release of this library?

• According to https://github.com/arduino-libraries/Arduino_MachineControl, latest release of Portenta Machine Control Library for Arduino is 1.0.2
• According to https://www.arduino.cc/reference/en/libraries/arduino_machinecontrol/, latest release of Arduino_MachineControl library is 1.1.0

Reading state of digital_output pins

As far as I can tell, there is no method like DigitalRead() to read the state of the digital output pins on the Portenta Machine Control. If it's not too much of a trouble, such functionality would be handy to directly have any of my remote processes read the state of a Machine Control unit. If not, I'll have to make intermediate variables to read out, but then there's a risk that the variable state is not exactly the digital output state, so I'd prefer reading the actual output instead.

I'd imagine something like digital_outputs.get() or digital_outputs.read(), in line with the current digital_outputs.set() functionality of this library.

Would that be possible?

Library does not compile with ArduinoCore-mbed:v2.3.1

  /home/runner/Arduino/libraries/Arduino_MachineControl/src/Arduino_MachineControl.h:15:10: fatal error: USBHost.h: No such file or directory
   #include "USBHost.h"

See this CI build.

add PWM channel 1 support

add the PWM support for channel 1: add a class that embed the Martino's code and test if works

New analog out CH3 and new analog out PWM pins

A fourth channel has been added

On V3.0 the analog out channels have been changed:
CH0 is now PJ11 (PWM4)
CH1 is now PK1 (PWM5)
CH2 is now PG7 (PWM3)
CH3 is now PC7 (PWM2)

Add internal voltage reference support to ANALOG IN

IoExpanderExample name

Name of the example should be DigitalProgrammable

Add support to load firmware with USBA connector

For version V3.0, currently the functionality is not supported in V2.0

Add GitHub Actions workflow to synchronise with shared repository labels

fix typo on menu item in example

rename from AutomationCArrier to ArduinoAutomationCarrier, in library.properties.

@svntti, @per1234 what you think about new name? @per1234 can you remind me the naming we use as official naming for our library

Crash on digitalinput.init()

The following sketch works on my Arduino Machine Control (blink digital output 0):

#include <Arduino_MachineControl.h>

using namespace machinecontrol;

bool state;

void setup() {
//  digital_inputs.init();
}

void loop() {
  digital_outputs.set(0, state);
  state=!state;
  delay(500);
}

However, when I uncomment // digital_inputs.init(); Portenta becomes unreachable (fixed by pressing reset button twice).

Can someone confirm this behavior?

Software used:

• Arduino IDE 1.8.19
• Arduino_MachineControl 1.1.0
• Arduino Mbed OS Portenta Boards 3.1.1

Board info:

Arduino loader
Magic Number (validation): a0
Bootloader version: 23
Clock source: External oscillator
USB Speed: USB 2.0/Hi-Speed (480 Mbps)
Has Ethernet: Yes
Has WiFi module: Yes
RAM size: 8MB
QSPI size: 16 MB
Has Video output: Yes
Has Crypto chip: Yes

Implement latch/retry function for digital OUT and digital PROGRAMMABLE

digital_out and digital programmable change .set function

Digital programmable is missing a function .set like the digital out section

RTD reading too slow

the 150 ms delay seems unreasonable. time to select analog muxes shall be much slower

Arduino_MachineControl/src/Arduino_MachineControl.h

Line 34 in 7697070

delay(150);

Analog output malfunction on AO2

It seems like AO2 pin is not correctly configured for PWM. There must be an issue in the AnalogOutClass section of the Arduino_MachineControl lib:
https://github.com/arduino-libraries/Arduino_MachineControl/blob/master/src/Arduino_MachineControl.h#:~:text=class%20AnalogOutClass%20%7B

The issue was discovered as follows: Even when AO2 is set to output 0V it always outputs 10V. I managed to replicate this result using the 'Analog_Out' sketch from Arduino_MachineControl library and configuring the Ao" as follows:

inside setup(): analog_out.period_ms(2, 4);
in loop(): analog_out.write(2, 0);

Add USBA VBUS shutdown feature

The enable of the power switch is attached to PB14

Add USBA flag feature

Flag pin of USBA power switch U24 is attached to PB15

Digital IN expander

Adjust the library to implement expander

InterruptIn error: irq channel conflict when BLE.begin() is called.

Hello,
I'm working with Portenta H7 using ArduinoBLE and Arduino_MachineControl libraries. The code is working well individually, but as I combine them the issue will be occurred. When BLE.begin() is called in setup() function, the red LED on board starts blinking right after that. I got the MbedOS printed messages here:

++ MbedOS Error Info ++
Error Status: 0x80FF0100 Code: 256 Module: 255
Error Message: Fatal Run-time error
Location: 0x807728F
Error Value: 0x0
Current Thread: main Id: 0x240054F8 Entry: 0x804D959 StackSize: 0x8000 StackMem: 0x24005540 SP: 0x2400D37C 
For more info, visit: https://mbed.com/s/error?error=0x80FF0100&osver=61600&core=0x411FC271&comp=2&ver=120200&tgt=PORTENTA_H7_M7
-- MbedOS Error Info --
InterruptIn error: irq channel conflict

RTC methods should be singolar

i.e setYear instead of setYears

Initializing the IO Expander breaks the serial (Micro-USB) interface

When calling the method 'digital_inputs.init()', the "standard" COM-Port (not the bootloader port) doesn't show up and the serial interface isn't working anymore.

Arduino Version 2
Visual Micro extension for Visual Studio 2019

How to use Hardware interrupts on Portenta H7 machine control

can someone help me to use hardware input interrupt on Portenta H7 machine control ?
even i tried to use input inside timer callback but it didn't work and it crash !
Thanks

Object name programmable_digital_io

It should be digital_programmables to follow the same style as digital_inputs

Thermocouples

temp_probes.selectChannel(2);
delay(150);
float temp_ch2 = temp_probes.tc.readTemperature(PROBE_K);
Serial.print("Temperature CH2 [°C]: ");
Serial.println(temp_ch2);

Insert delay like in example

"Device attach failed" USB Host in the portenta machine control

I connected a USB-UART connector from the bms to the USB-A port in the PMC, and upload this USB_Host.ino example code. The serial monitor output shows like this

RHUB FS:0      Enable
DEV  FS.00     Allocate pipe, in = 0, out = 1
DEV  FS.01     Re-allocate pipe, in = 0, out = 1
DEV  FS.01     FS device, VID:1a86 PID:7523
ITF  FS.01.0-0 Vendor interface init
ITF  FS.01.0-0 Ep Info: 3 eps, in_ep:[82,2,32], out_ep:[02,2,32],
DEV  FS.01     Device has 1 interfaces
RHUB FS:0      Device attach failed

whenever i unplug and plug the connector from the USB-A port, the output in the serial monitor changes like this...

RHUB FS:0      Disable 4
ITF  FS.01.0-0 Vendor interface deinit
RHUB FS:0      Disconnect
RHUB FS:0      Connect
RHUB FS:0      Already enabled
RHUB FS:0      Enable
DEV  FS.00     Allocate pipe, in = 0, out = 1
DEV  FS.01     Re-allocate pipe, in = 0, out = 1
DEV  FS.01     FS device, VID:1a86 PID:7523
ITF  FS.01.0-0 Vendor interface init
ITF  FS.01.0-0 Ep Info: 3 eps, in_ep:[82,2,32], out_ep:[02,2,32],
DEV  FS.01     Device has 1 interfaces
RHUB FS:0      Device attach failed

what do i have to do to make a successful connection?

Dual Core Example/Functionality

There isn't an example to use the dual core feature of the H7 controller. The current library won't compile for M4 core unless #ifdef CORE_CM7 ... #endif are used to contain the RS485 and COM classes.

The Machine Control board is advertised to feature the dual core power of the Portenta H7 controller. However, the current library doesn't allow for that.

PMC freeze when using ArduinoBLE with Arduino_MachineControl included.

Portenta Machine Control (PMC) crash when the begin function is called for the ArduinoBLE library when Arduino_MachineControl.h is included in the same sketch.

To reproduce

1. Upload the Portenta BLE example without changes (https://docs.arduino.cc/tutorials/portenta-h7/por-ard-ble).
2. Verify functionality. (Optional).
3. Include header file Arduino_MachineControl.h. (#include <Arduino_MachineControl.h>)
4. Upload sketch and note that the Portenta Machine Control will freeze.

Library versions used

• ArduinoBLE v1.2.1.
• Arduino_MachineControl v1.1.0.

Additional context

Additional reports

• #73 (comment)
• #73 (comment)

Digital programmable example as Digital outputs

Replicate the same structure of digital output example in digital programmable.
This still needs the .set issue to be solved

Serial.print doesn´t work

void setup(){
  Serial.begin(19200);
}

void loop(){
  Serial.println("test");
}

this code is output to the IDE monitor, but not to the USB COM.
If I put this code on a UNO, I can get it with another program, just not with the Portenta Machine controller.
Any suggestions?

Mode for analog in channels should be set individually

The analog in channels support three modes:

• 0 - 10 V
• 0 - 20 mA
• NTC (resistance)

The modes are set in functions like this, for all three channels:

Arduino_MachineControl/src/Arduino_MachineControl.h

Line 265 in a9845d2

void setNTC() {

Hardware supports to configure the channels individually, as all ANALOG_IN_CH_SEL lines are connected to individual MCU pins.

An API like this would be great (for all three modes, here shown with NTC mode):

analog_in.set0_10V(); // sets all analog in channels (existing)
analog_in.setNTC(2); // sets mode for channel 2 (new)

raw_adc = analog_in.read(2); // esisting

---

Related: #101

Rename from AutomationCarrier to Portenta Machine Control

before launch, rename everything reflecting the official name.

Allow full bank reads from IO expander

Hi all,

i'm using the Arduino Machine Control to capture signals from sensors on production machines and send them via USB/serial port to a PC where the data is logged. Usually only the 8 digital inputs are needed.
Since i want to get the signals every millisecond, i realized that reading the signals one by one using
digital_inputs.read(...)
takes too much time.
Instead i added methods to the ArduinoIOExpanderClass with which i can use TCA6424A::readAll(...) and TCA6424A::readBank(...).

I made some simple measurements by comparing the value comparing from micros() before and after running the "read" methods.
I also changed the I2C clock frequency.

1. Reading channel 0 to 7 one by one @100kHz: 3588 us
2. Reading channel 0 to 7 one by one @400kHz: 1337 us
3. Reading bank 0 @100kHz: 452 us
4. Reading bank 0 @400kHz: 169 us
5. Reading bank 0, 1 & 2 one by one @100kHz: 1345 us
6. Reading bank 0, 1 & 2 one by one @400kHz: 501 us
7. Reading all banks @100kHz: 653 us
8. Reading all banks @400kHz: 242 us

By running I2C at 400kHz and using the readBank(...) method I get all 8 bits of bank 0 within ~170 us which is sufficient for me.

Would it be possible to add such methods to ArduinoIOExpanderClass to have them available "out of the box"?

Best regards
matt

Digital output CH1 and CH2

Correct CH1 to new value: PH_9
Correct CH0 to new value: PJ_9

RTD CH sel pins must be changed

Change CH0_SEL to PA_0C
Change CH1_SEL to PI_4
Change CH2_SEL to PG_10

GPIO pins go high on startup

Dear all
The GPIO pins seem to go high on startup when calling digital_programmables.init(). I have fixed it by setting the Pin to off before setting the pinMode.

Line 86 of ArduinoIOExpander.cpp looks now like this. Everything seems to work as intended

  void ArduinoIOExpanderClass::initPins()
  {
      if (_tca.getAddress() == IO_ADD) {
        PinStatus status = SWITCH_OFF;
        set(IO_WRITE_CH_PIN_00, status);
        set(IO_WRITE_CH_PIN_01, status);
        set(IO_WRITE_CH_PIN_02, status);
        set(IO_WRITE_CH_PIN_03, status);
        set(IO_WRITE_CH_PIN_04, status);
        set(IO_WRITE_CH_PIN_05, status);
        set(IO_WRITE_CH_PIN_06, status);
        set(IO_WRITE_CH_PIN_07, status);
        set(IO_WRITE_CH_PIN_08, status);
        set(IO_WRITE_CH_PIN_09, status);
        set(IO_WRITE_CH_PIN_10, status);
        set(IO_WRITE_CH_PIN_11, status);
        
        pinMode(IO_WRITE_CH_PIN_00, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_01, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_02, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_03, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_04, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_05, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_06, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_07, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_08, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_09, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_10, OUTPUT);
        pinMode(IO_WRITE_CH_PIN_11, OUTPUT);
        pinMode(IO_READ_CH_PIN_00, INPUT);
        pinMode(IO_READ_CH_PIN_01, INPUT);
        pinMode(IO_READ_CH_PIN_02, INPUT);
        pinMode(IO_READ_CH_PIN_03, INPUT);
        pinMode(IO_READ_CH_PIN_04, INPUT);
        pinMode(IO_READ_CH_PIN_05, INPUT);
        pinMode(IO_READ_CH_PIN_06, INPUT);
        pinMode(IO_READ_CH_PIN_07, INPUT);
        pinMode(IO_READ_CH_PIN_08, INPUT);
        pinMode(IO_READ_CH_PIN_09, INPUT);
        pinMode(IO_READ_CH_PIN_10, INPUT);
        pinMode(IO_READ_CH_PIN_11, INPUT);
      } else {
        pinMode(DIN_READ_CH_PIN_00, INPUT);
        pinMode(DIN_READ_CH_PIN_01, INPUT);
        pinMode(DIN_READ_CH_PIN_02, INPUT);
        pinMode(DIN_READ_CH_PIN_03, INPUT);
        pinMode(DIN_READ_CH_PIN_04, INPUT);
        pinMode(DIN_READ_CH_PIN_05, INPUT);
        pinMode(DIN_READ_CH_PIN_06, INPUT);
        pinMode(DIN_READ_CH_PIN_07, INPUT);
      }
  }

So far I have not observed any unwanted effects from this change

IOExpander: digital_inputs.readAll() Out of sequence?

When trying to read the digital inputs all at once on the Portenta Machine Control, the resulting bit order seems to be out of sequence in the output variable. I may have traced it down to this enum in ArduinoIOExpander.h:

Arduino_MachineControl/src/utility/ioexpander/ArduinoIOExpander.h

Lines 74 to 83 in ca7ff9b

	enum {
	DIN_READ_CH_PIN_00 = TCA6424A_P10,
	DIN_READ_CH_PIN_01 = TCA6424A_P05,
	DIN_READ_CH_PIN_02 = TCA6424A_P04,
	DIN_READ_CH_PIN_03 = TCA6424A_P02,
	DIN_READ_CH_PIN_04 = TCA6424A_P01,
	DIN_READ_CH_PIN_05 = TCA6424A_P00,
	DIN_READ_CH_PIN_06 = TCA6424A_P07,
	DIN_READ_CH_PIN_07 = TCA6424A_P06,
	};

I would expect that the physical pins on the board would match the bit sequence in the output of readAll(). However the sequence on the board from LSB to MSB is:

DIN_READ_CH_PIN_05,
DIN_READ_CH_PIN_04,
DIN_READ_CH_PIN_03,
DIN_READ_CH_PIN_02,
DIN_READ_CH_PIN_01,
DIN_READ_CH_PIN_07,
DIN_READ_CH_PIN_06,
DIN_READ_CH_PIN_00

This seems to match the pattern in the enum above.

Is it possible to return the readAll() in a sequence that matches the board layout?

Use case: I'm trying to input an 8-bit pattern to the DIs which I can translate to an integer and then use an index to an array. I'm a novice at all of this, so apologies if I'm just missing something simple.

digital_programmables.init() crash

I have a huge problem with the digital_programmable pins. When i have 24 V connected the board crashed when running the .init() function. But when there is no 24V the function runs without problem.
I tried many things, like another sequence of functions in the setup, but i doesn`t work.
Does anyone has the same problems or an idea?
A code example does not help here, because i can move the digital_programmables.init() at any position in the setup().

Please,help :)

I2Cdev is old and has major issues

Arduino_MachineControl/src/utility/ioexpander/I2Cdev.cpp

Lines 285 to 286 in ca7ff9b

	Wire.beginTransmission(devAddr);
	Wire.requestFrom(devAddr, (uint8_t)min(length - k, BUFFER_LENGTH));

Surrounding Wire.requestFrom() with Wire.beginTransmission(devAddr); / Wire.endTransmission(); is not the correct usage of the Wire lib.

This bug has been fixed in I2Cdev already 2 Years ago in
jrowberg/i2cdevlib@98a3b4e

RS-485 full duplex example disables the receiver when sending data

Hello,
At the moment, the RS-485 full duplex example disables the receiver when sending data. This defeats the purpose of full duplex:

comm_protocols.rs485.noReceive();

comm_protocols.rs485.beginTransmission();

comm_protocols.rs485.print("hello ");
comm_protocols.rs485.println(counter++);

comm_protocols.rs485.endTransmission();
        
// Re-enable receive mode after transmission
comm_protocols.rs485.receive();

If this is not necessary, the example should be changed to leaving the receiver enabled.

If this is necessary (perhaps due to a physical limitation of the Portenta Machine Control that requires the receiver to be disabled when sending data???) then the limitation should be clearly documented.

PT1000 isn´t compatible

In the "Temp_probes_RTD" example sketch, you describe that a PT1000 is also possible:

Arduino_MachineControl/examples/Temp_probes_RTD/Temp_probes_RTD.ino

Lines 21 to 24 in 7e5974e

	// The value of the Rref resistor. Use 430.0 for PT100 and 4300.0 for PT1000
	#define RREF 400.0
	// The 'nominal' 0-degrees-C resistance of the sensor
	// 100.0 for PT100, 1000.0 for PT1000

Now your support writes me that this is not possible. Please take that out of the comment in the code, just causes confusion. Thanks :)

Example names

Some examples have _Example in the name, some don't, I would uniform them all removing the _Example in the names

Digital programmable has "memory"

If the digital programmable channels are left "ON" (so the channel is ON), in another example, they will remain closed even with other examples

We need a function that initialize the board shutting down digital programmables if they were on on another startup; the IO expander has probably a memory which remembers what was happening