Hello Armin,

I am trying to enable netPI wifi mode - Client, but not able to work with. i already recovered my netPI & installed new firmware V 1.1.5.0, but still no able to access it in wifimode.


I can accaess it default DHCP.

pls sugegst how to proceed.

BR

Madhumati

Attached Files

Thumbnail(s)
       

The Raspberry Pi CPU has 16 custom OTP cells that can be programmed from a user application one time.

OTP cells are interesting if you want save a permament license code on your hardware for example that cannot be deleted any more.

The Raspberry Organization dedicated an extra article on their web site how to use the OTP cells here: https://www.raspberrypi.org/documentatio.../README.md. For own tests the referenced shell command

The netX programming examples now also include an example for POWERLINK slave and Modbus/TCP server.

Included examples:

• PROFINET IO-device
  
• EtherNet/IP adapter
  
• EtherCAT slave
  
• POWERLINK slave       NEW
  
• Modbus/TCP server     NEW
  

Hello,

in order to run an example program / container over the NetPi on the Profinet fieldbus system via the image "hilschernetpi/netpi-netx-programming-examples" I downloaded the corresponding device description file from GitHub / electronic-data-sheets following the instructions on DockerHub.

This is however faulty. When opening the file via an texteditor, parsing Errors are displayed and the device description file can not be imported into the Simatic Manager because it seems to be faulty. Furthermore a .bmp and a .ico file are available on github. These too are not able to open after download.

Now my question:
Is there a more up-to-date working device description file on another website?

I would very much welcome further solutions.

Thank you and best regards

I want to highlight a Docker feature that is very useful in case you spread your applications among multiple containers: Docker features an embedded DNS server in case you use USER-DEFINED BRIDGED NETWORKS.

The problem:

Often spread containers need to talk to each other over http, ftp, mqtt and others over TCP/IP directed channels. Whenever containers are deployed and operated in default bridged-network mode they get an IP address such as 172.17.0.2 or 172.17.0.3 and so on automatically. The problem now is that the IP address assigned is not constant and may vary each time a docker host platform like netPI is repowered and the containers a restarted. So if a container application then wants to talk to any other container over a set and fixed IP address this will lead sooner or later to a problem in case the destination IP address is getting different during reboot times.

The solution:

The problem can be solved if instead of ip addressing scheme a name adressing scheme is used supported by the Docker embedded DNS server. The best of it is that you do not need to define any extra name ... just using the container's name is enough to address it. For example if you named a container mosquitto then you can just call ping mosquitto from any other container and you get response. Or supposing you started an influxdb database container named influxdb supporting a REST API over port 8086 then simply address it with http://influxdb:8086.

There is one thing you need to consider: the embedded DNS server works in user-defined bridged networks only and not with the default bridge network (cause of compatibility reasons) as explained on the official Docker web site here. So you have to create an own network first as the picture illustrates:

   

Later before you deploy your containers you have to select your user-defined network instead of the default bridge to let them participating this network

   

Thx
Armin

Hello Armin,

Can customer access to netPI through CLI?
or Only Portainer.IO GUI is used? 

BR

Madhumati

LED sticks like these here https://www.blinkstick.com/ are nice gimics to extend netPI by further lights.

One major concern is the inrush current that arises when the LEDs are switched on. With blinkstick LEDs their triple color LEDs for example are directly connected to USB +5V without any resistor and hence take full effect on the USB host's (netPI) +5V power supply. The inrush current may vary from 1 to 80amps if you follow forums and user stories on the internet if you search for terms like "inrush current high power LEDs". Nobody can really tell you the exact current draw in the event you switch them on except you measure it by yourself.

netPI's 4x USB ports are limited to deliver 1000mA of current over all 4 ports in maximum. Higher values are out of specification and could lead to USB drop outs in terms of communication inpendent if it the current draw is static or pulsed for even some µsecs. Linux for example would report the loss of USB connection similar to somebody unplugging the USB device and reconnecting it.

In netPI operates a step-down regulator XR76205 that turns the 24V input voltage to 5V USB. It has a fast load transient response when the output USB load changes. It is good to react on cases where a new USB device is plugged in and he regulates the voltage back to 5V after the first current impulse to keep the voltage in all cases higher than 4.75V. But for LEDs (and multiple of them at a time) with unpredictable inrush current during their switch on phase this guarantee for a proper operation cannot be given.

So please avoid using the LED sticks and stripes especially if you are operating additional USB devices the same time needing a 24h proper USB connection.

Hello,

i want to upgrade my netpi RTE3 without making a recovery.
I will always loose everything when i want to make an update.

I want to use the new features of the new versions. Is there a possibility to update the netpi whout loosing the configuration?
It would also be great if it was possible to update the netpi via the Web-GUI. Because we want to use a lot of netPIs in the future and it is not very pracicable when i have to update every netPI via USB and also lost the configuration of it.

Thanks!
Hannes

Some applications you like to run on a netPI need far more access rights to a Host Linux than netPI's preloaded OS and restricted Docker deamon allows you. Typical application examples are discussed in the threads https://forum.hilscher.com/thread-368.html or https://forum.hilscher.com/thread-379.html.

What we offer to OEM customers as alternative is a netPI version coming without SD card (which was sealed till january 2019) and software at all. You in turn add your SD card containing your own software to these units and run them as you like. 100% compatibility to a Raspberry Pi 3B guarantees compliance to all software offered by the Raspberry Organization at https://www.raspberrypi.org/downloads/.

The alternative parts can only be ordered through Hilscher sales. They are not available on Amazon.de or Hilscher web shop.

Option A (edit March 2020: Both following part numbers are obsolete. Buy a standard netPI instead, since SD card is no longer sealed since 2019 and can be replaced with own one. So a etPI is as good as the obsoltet EVA products)  

       Part number 1321.429, named NIOT-E-TNPIR3EVA - Evaluation version of single netPI RTE 3
       Part number 1321.439, named NIOT-E-TNPIC3EVA - Evaluation version of single netPI CORE 3

• Each part includes a single piece of device that comes in the same card board box like a standard netPI
  
• The device is preassembled and housing upper and lower part are screwed together as with standard netPI
  
• The device does not included an SD card, the inner SD card slot is left empty. It needs an SD card you have to add  to run. You need to open the case.
  
• There is no Hilscher software provided. Software responsibility lies with the customer.
  
• The part is made for evaluation purposes only to give customers a chance to evaluate the hardware along with their own software
  
• The part is slightly higher in price than a standard netPI, cause we create it on demand in single pieces making manufacturing more expensive
  

• Each part  is an OEM package of 40 pieces placed in a big card board box with separators in between
  
• All devices are preassembled and the PCBA is embedded and screwed to the housing lower part
  
• The housing upper parts come loose and just are slid over the lower parts. Housing upper and lower part are not screwed together
  
• The devices do not include an SD card, their SD card slots are left empty. Own SD cards have to be added to run
  
• All 160 screws - 4 needed for each unit - come in a big bag. They attach the housing upper part to the lower part when screwed
  
• There is no Hilscher software provided. Software responsibility lies with the customer.
  
• This package is significantly cheaper in relation to price/unit as those offered on amazon or web-shop
  

Dear netpi users,

I'm starting to grow grey hear from the attempt to hotplug usb devices.
At the moment it is impossible to have in running container usb devices taken off and reattached after a while.

the easiest way to test this is by
-privileged mode
-device /dev/bus

lsusb -vd XXXX:XXXX
XXXX for example the vendor and product id of a hid-device (keyboard)

now remove the keyboard
reattach it
run lsusb again
now you see "Couldn't open device, some information will be missing" at the beginning of the output.
and you can't access it anymore

Same for tty devices
-device /dev/ttyACM0

start container
everything fine
run "udevadm monitor"
remove and attach the device again
now you see the device is not connected back to the device path /dev/ttyACM0 instead it takes /dev/ttyACM1

an easy solution would be if the restrictions of the netpi wouldn't be this restrictive
-device /dev
now the tty would get connected again

-volume bind /dev/bus/usb:/dev/bus/usb
now the usb hid-device could reconnect

I hope anybody has a solution to this problem of the missing USB hotplug functionality or we have to buy other devices for our customers with over 100 devices just in one production system, more would follow.

Thank you very much in advance
Sven