Hi,
we got several e-mails about re-design of iMX233-OLinuXino to fit inside DIN rail and possibility to connect to other IO DIN rail modules, this is why I set this topic to may all interested parties to discuss.
What I think may be useful is iMX233 DIN module with side UEXT which allow another DIN modules to snap-together, all DIN modules will have pass-through UEXT connectors male/female on both sides so UEXT connection always is available to the next modules too.
through UEXT we can make IO relays/Optoisolated 4/4 modules, GSM-DIN rail, module, etc.
The base iMX233 DIN module will have LCD, WIFI, some buttons, what else?
Tsvetan
Hi,
features used in expensive PLCs are: RS232, RS485, Ethernet.
Ethernet you already have.
RS232 is nice-to-have, because you can communicate with cheap HMIs.
40 opto-isolated GPIOs (NPN or PNP output) would be good, but to lower BoM 12DI/12DO is enough.
2 Analog inputs are good, you can multiplex them.
Would be possible 1-wire master?
If you could fit it below 100EUR, you win.
Standard is 24V power supply.
This sounds like a great idea Tsvetan!
Rather than integrating WiFi (not so common on a PLC) I'd recommend the following on the front panel of the controller:
- serial console
- ethernet
- RS485 (2 or 4 wire for ModBus)
- USB host (for flash drive, WiFi, or additional serial port)
- power input
Kean
Necessary UEXT modules:
Count always at least 16I/O on one module, because you can :-)
8+8, 16+0, 0+16. If you could make 32I/O version, even little more expensive than 2x16.
Rule of thumb on todays market is 4-5 EUR/IO.
Better is to make opto-isolated transistor output - you could fit more I/O on DIN Rail.
Example for enclosure:
http://www.alibaba.com/product-gs/338663366/din_rail_plc_enclosure.html (http://www.alibaba.com/product-gs/338663366/din_rail_plc_enclosure.html)
Tsvetan,
sounds like a really good plan :D ! I had the same thing in mind with the Uext connectors, this way it's really easy expandable.
Only the LCD and the wifi ... I don't see the use for a lcd on a din rail because most of the time (99%) the closet which hold the plc will be closed, you may create a lcd panel holder with Uext for that ...
Second, since mostly the envoironment where the plc will be at has some noise from electricity cables which is not so good for (I think) the wifi and since much of the industrial closets are fully metal I don't know if the wifi can get through.
The base module should have only the base controls, some buttons (reset and maybe one user), some status leds (power, up and user), the sdcard and then as connection ethernet (wired prefered), usb, Uext (male/female), power (can maybe be given through Uext or wired through the din on screws).
Optionally if there's some room, the free screws of the din enclosure can hold some gpio's. All the other communication is already available through the Uext (rs232, rs485, I2C, SPI) and can be accessed with breakout modules.
For the I/O modules I think the easiest way is to keep it in numbers of 8's (bytes) since there are a lot of I2C I/O expander already there, same as ADC's and DAC's pcf8574, pca9655, mcp23017, max127, tda8444, etc. Those will get you pretty far.
I'm also experimenting with the modio for the moment. I'm using the free "select" pin of the Uext connecter and use it as an interrupt. So everytime something changes in the I/O's an interrupt is generated and data can be read (the same way for ex the pcf8574 does). This can not be done for analog signals of course.
PS: a dream solution would have a bit more ram and a faster µP :). I tried to run domogik (domogik.org), but it crashed due the less ram ...
hello ,
I produce digital and analog I/O boards for my own use
maybe this shortens development time of the PLC you are developing
look below for 24 / 12 digital I/O boards ( most bottom photo )
http://www22.brinkster.com/anotherbrick/index9.htm
the boards have 26 pin flat cable connection to the CPU - the access to I/O's are memory mapped I/O
I used the boards in industrial environment - no problem so far
Quote from: jeroends on October 02, 2012, 06:08:14 PM
PS: a dream solution would have a bit more ram and a faster µP :). I tried to run domogik (domogik.org), but it crashed due the less ram ...
will 256MB be enough? A13-MICRO with Cortex-A8 @ 1GHz should be fast enough
Quote from: olimex on October 02, 2012, 09:25:33 PM
will 256MB be enough? A13-MICRO with Cortex-A8 @ 1GHz should be fast enough
More than!! I have for the moment a domotic system + server (webserver the one hosting my sites, sql, file etcetc) running on a mini pc running @ 500MHz (geode lx800) and 256Mb ram (shared with video), so running @ 1Ghz wil do ;) (don't underestimate the power when not running a xsystem)
then I will send you one A13-MICRO from the developer edition (when we have them) so you can check your software with it!
Tsvetan,
could I have one more idea? :-) Maybe would be enough PLC shield or UEXT extension for Arduino. Normal PLCs have memory counted in kBytes and it is usually enough. 8 digital inputs / 8 outputs or better 16/16 I/O for 24V
in what language you will program the arduino plc?
MOD-IO even now adds unlimited number of IOs to Arduino
I don't mind to programm it in Arduino pseudo-c. What I see is that graphical tools are still used, but guys from electro-department tend to move from away ladder diagrams. I know of MOD-IO, but just four outputs is too little for me. I will not give 10 these boards in my rack. And noone would give me state approval to use it in home installation :-)
Hi,
This is a great idea and if materialized, a good break through.Beleive the whole design should be modular but sufficient enough size for small to large installations.
The CPU or base model is good enough iMX233-OLinuXino had the processing power and memory and suitable UEXT connector for adding Communication modules like rs-485, rs-232 and IO modules.
my wish list would be
Real time clock
Modular IO in 8 and 16s should handle current/voltage/thermistor/thermocouple/counters,volt-free contacts,what i see missing in the UEXT MOD IO are Analog outs for voltage and current.
M-BUS interface card for reading meters
Like earlier comments the display module can be panel mounted ,small LCD have very little use
I use this Din box
http://www.mouser.com/Search/ProductDetail.aspx?R=DMB-4772virtualkey56310000virtualkey563-DMB-4772Normally it housed the STM32 with Can Bus.
I was looking to use the A13/iMX233 and my User Interface for RV System.
http://roadwarrior.free-man.com/can/rvcan/rv-C-projects.shtml
The wifi is used to interface to tablets through the RV.
So the display as such is an app on the tablet.
the Din Box with the A13/iMX233 could connect to the Master STM32 through the UEXT.
the A13/iMX233 will have a touch screen LCD for local parms.
The problem using present UEXT IO modules is they need CE approval in commercial assembly, using 230V relays.
To avoid expensive approval, IO module could have open collector circuit to drive external relays. For example RT relay with DIN rail socket are both approved and cost <10€.
Instead onboard relays, I would like to have more analog inputs and maybe more than 10bits resolution. Onboard circuitry or option for various type temperature sensors would be nice.
Timo
for more analog inputs you could use ie. a max127: 8 channel 12bit 0/5 -5/5 0/10 or -10/10V input A/D with a few external components. ideal for measuring industrial signals.
Ideal Analog Industrial signals are Inputs selectable for 0-20mA, 4-20mA,0-10V,RTD, ThermoCouple
and Outputs programmable for 0-20mA, 4-20mA,0-10V.Are there UEXT modules for the same? , or are there any third party boards compatible ( low cost ,low speed 10/12 bit resoultion) . I am already working on the software side ,this is the only feature missing,after which i will buy my maxi and work on porting the software.
I have found this interesting http://www.analog.com/en/content/cu_eb_plc_demo_system/fca.html How ever its rs-232 based , would appreciate some inputs.
Hi,
CamdenBoss CNMB6 DIN rail box PCB B (middle) size is 57x102mm. Olinuxino iMX233 MaxiPCB size 54.6x96mm. You could fit Olinuxino into the box adding some empty area around OLinuXino Maxi PCB and using UEXT and GPIO connectors facing up.
http://docs-europe.electrocomponents.com/webdocs/105b/0900766b8105ba74.pdf
The height of the USB connector might be problem.
The downstars of the box (PCB A) could be used for IO board with terminal connectors.
Timo
Hi,
that's a nice idea. Actually module that has both male and female UEXT connector, like MOD-IO, doesn't are really pass-trough because extend UEXT only partially. For example MOD-IO extend only the I2C to bridge multiple IOs.
I will solve building custom IDC10 cable (one female two male), because I need both SPI and I2C for two different modules, but having a direct extension of UEXT make things easy.
May I give one suggestion, now in the Industrial Automation there is the concept of intellingent junction box, extend field cables is a costly and annoying matter, so many companies (like the one where I work for) is selling modules that move the electronics directly in the junction box and then connect it via ethernet or RS485 to a main controller.
This is just an extreme concept of distributed system that can easily apply also for home automation, where is not so confortable to have a central PLC and run cables over the home. You have yet the hardware, the MOD-IO, just need a more powerfull microcontroller to handle an UEXT communication module. May I suggest an AVR one, to get in touch also with the Arduino community.
So your architecture will be the OLinuXino as central controller that may be extended via IDC10 calbe or via ethernet/wireless UEXT module to their remote I/O. On the deterministic (real-time) point of view, with Ethernet is no longer a problem.
Then there will be the certifications, CE is not enough in Industrial Automation because needed certification very on the plant type, but certification cost money and to keep the price lower these cannot be offered. But this type of PLC or distributed IO may be applied in a lot of not industrial cases.
Regards,
Dario.
For some reason i dont have much faith in using I2C/SPI as a 'backplane' bus. Theyre not really meant for this kind of application, going off PCB. Multiple times i have seen I2C busses lock up because of some sort of device borking and keeping the clock line stuck.
Would'nt a more 'industrial' bus like CAN be a more sensible choice?