mizar32 Lua board on sale
Locked
12
12
 
|
Thiago Naves |
Re: [SPAM] Re: ARM9 Embedded PLC
|
Just bought one of those. I'll pick it up tomorrow... On Dec 2, 2012 2:56 PM, "Quentin Barry" <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Quentin Barry
Hi,
On Sun, Dec 2, 2012 at 1:55 PM, Quentin Barry <[hidden email]> wrote:
Is your Modbus code open source and available on an online repo?
Thanksssssssss Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Quentin Barry |
Re: [SPAM] Re: [SPAM] Re: ARM9 Embedded PLC
|
|
Quentin On 2012/12/30 02:27 AM, Dado Sutter wrote: Hi, _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: [SPAM] Re: [SPAM] Re: ARM9 Embedded PLC
|
|
On Sat, Dec 29, 2012 at 11:59 PM, Quentin <[hidden email]> wrote:
Cool! No hurry. Thanksssssss
Sounds nice! I've never used Modbus over the air.
Very cool. Thanks for sharing. It seems like it deserves to become a specific optional module for eLua apps in the future.
Best wishes Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
I'm glad to hear that "real" programmers are using PLCs because I have a PLC based project on my to-do list. I have read a book on the topic and it was so painful. The concepts are so simple but their explanations are so complex. I can understand from a historical perceptive how ladder logic came about, but in modern times, I cannot understand why people try to explain the programming primitives in terms of coils and switches. I feel like I'm missing something basic. I think I remember reading that ladder logic is a "hard" real-time programming language. I know there are other languages for PLCs but ladder logic seems to be the dominant one. Do "real" programmers use ladder logic?
On Sun, Dec 30, 2012 at 12:47 PM, Dado Sutter <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
As an automation software developer, I'll add a few more off-topic comments:
-- Yes, ladder logic is still widely used. The better vendors support IEC61131, which includes classic ladder, structured text (ST; Pascal/Basic style syntax), plus 3 other choices. -- Yes, ladder logic is still awful. Even in ST, calling functions is painful, and, on the Panasonic FP0-R's I normally use, calling functions doesn't save code space; instead, the compiler treats them as macros. -- However, IEC61131 with ST is much better than many other industrial automation languages I've had to use, such as Allmotion, Schneider/IMS MDrive, Moog/Animatics SmartMotors, Galil, and a whole bunch of others. -- PLC's are very much real time; the code is executed as a cyclical loop, with inputs read at the start, then all the code is executed in order, at the end the outputs are set and then communications are handled before starting the next loop. -- The only decent book on real world PLC programming is Gary Kirckof's Cascading Logic, which is small but pricey. Also, check out the Automation Primer site ( http://www.automationprimer.com ) for an idea of real world automation. -- There can be political reasons, too; for example, I've heard at many union companies, the electricians can only use ladder logic, but not a higher level language such as C (because of union rules). -- I'm happy I can do most of my development in .NET (VB.NET and C# - I'm tempted to use F#). Ladder logic can be done well, but it's easy to create spaghetti code. A hard real time high level scripting language would be wonderful.... --Tony On Fri, Jan 4, 2013 at 9:10 AM, Mike King <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Sorry for the off-topic questions, and thank you for your comments. This project of mine is a nightmare. I have to rewrite (long story) the logic of some of our machines. The original code was developed in Japan, and it has very few comments in it. It has thousands of lines of code with very few variable (coils) names when it probably should have only taken a hundred or two hundred lines of code to implement. It is the worst spaghetti code I have ever seen.
On Fri, Jan 4, 2013 at 2:32 PM, Tony <[hidden email]> wrote: As an automation software developer, I'll add a few more off-topic comments: _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Quentin Barry |
Re: [SPAM] Re: [SPAM] Re: [SPAM] Re: ARM9 Embedded PLC
|
|
In reply to this post by Tony-12
If I may add my two cents here...
Before the advent of the Z80, 8051, 8085 families and other CPUs similar from various vendors, most machinery was controlled with relays, contactors and timers. A good example would be the classic star-delta starter circuit with hardwired interlocks. The first computer bug found was a moth stuck between relay contacts.
Ladder is easy to use and easy to read, as long as each element is labeled. PLCs were originally designed to be deterministic. The original concept did not involve multi-tasking. In fact if one wants to control a servo motor for example, a dedicated card with an application specific CPU is fitted. This allows the card to track the encoder without missing any pulses and to exercise precise control over the servo motor. All the main PLC CPU program does is to supply the Servo card with positioning data.
Another factor to consider is deterministic control - i.e. to set up a fixed scan cycle allows one to control PID loops easily. The Telemecanique and Mitsubishi PLCs are some of the models that I have worked on that have this facility. For example if all your code executes in 87 mS then you can set the scan cycle to 100 mS. So for 13 mS it is idle after a scan and then it will process all the input signals - analogue and digital. It will run through the ladder logic, and PID loops, update the outputs and process the communication layers. It will then "rest" again for 13 mS. Instead of wasting the idle time, one can insert a self test algorithm here, that executes for 13 mS and then yields control over to the main tasks. At the end of the next scan the self test can resume where it left off and so the cycle repeats.
Historically there has been much debate about the use of Ethernet in Industrial control systems. That's why there are so many different protocols out there. Some people feel that Ethernet is not deterministic. The PLC vendors - i.e. Mitsubishi use Melsec Net - which is deterministic. This is especially important if you have one PLC controlling the head motor or VSD of a 6 Km conveyor belt and another controlling the tail motor or VSD of the same conveyor belt. Synchronisation of data is critical and both VSDs must run at the same speed and accelerate and decelerate at the same time. If this was not the case, at the minimum the conveyor belt will snap, at the worst the system can oscillate, and if the oscillation happens to be at the "right" harmonic it just gets amplified and amplified until the structure collapses - every metal structure has a harmonic which it is susceptible to.
With the advent if IEC 61131 it allows the software developer to create function blocks with pre-defined inputs and outputs. The control logic resides in the function block. One can thus create a generic all purpose motor drive function block for example. This would include inputs for interlocking purposes, fail safe purposes, and it would also check the health of the motor. It is the function of the software developer to test this algorithm vigorously. This same function block can then be used to start pumps, motors etc. and to turn the motor off if some other device in the field fails. For example, motor 1 may need motor 2 to run before it can turn on. If this condition is met then motor 1 will start - however if motor 2 fails at any instant, motor 1 must also turn off.
In my experience I have found that by creating function blocks (call them sub-routines to which you pass and receive parameters) one can enable the Electricians to develop their own code using standardised modules. This allows them to debug the system in real time. For example, one mine in South Africa is 2 miles deep. Plugging into the system on the surface allows them to fault find the system and save time. They soon get an idea of what has failed and they then know which components to take with them underground to repair the system.
As to connecting to a SCADA system, Ethernet as a backbone is ample. Using Melsec Net I have made online real time changes to the Slave PLCs which are located kilometers away. Granted we made use of fibre optic cable, but we could still achieve this. Or else I could "look" into the field PLCs and see what was preventing the system from starting. Faulty limit switches, Pull Switches etc.
On a parting note, PLCs are extremely robust animals. All the field signals are isolated from each other and from the PLC electronics. So if some monkey connects 380 V to a 4 - 20 mA analog input channel, only the analogue card will need replacing. I have personally witnessed an electrician connect 380 VAC to a Mitsubishi PLC power supply. He mixed up the neutral wire with another phase. All that happened is that the circuit breaker tripped. He rectified his mistake, and to my amazement the PSU still functioned.
On the downside, IEC 61131 compilers are expensive. It's fine purchasing one for a particular brand of PLC, but if you suddenly land a job which has a Siemens PLC then you have to purchase that compiler too. PLCs are also expensive, but they are robust industrial specified devices which run for many years. A PC can never replace a PLC. They just do not have the MTBF of a PLC, and down time means a loss in revenue. I would like to see how long a PC lasts in a coal mine before it either fails or causes a fire.
Regards
Quentin
As an automation software developer, I'll add a few more off-topic comments:
-- Yes, ladder logic is still widely used. The better vendors support IEC61131, which includes classic ladder, structured text (ST; Pascal/Basic style syntax), plus 3 other choices. -- Yes, ladder logic is still awful. Even in ST, calling functions is painful, and, on the Panasonic FP0-R's I normally use, calling functions doesn't save code space; instead, the compiler treats them as macros. -- However, IEC61131 with ST is much better than many other industrial automation languages I've had to use, such as Allmotion, Schneider/IMS MDrive, Moog/Animatics SmartMotors, Galil, and a whole bunch of others. -- PLC's are very much real time; the code is executed as a cyclical loop, with inputs read at the start, then all the code is executed in order, at the end the outputs are set and then communications are handled before starting the next loop. -- The only decent book on real world PLC programming is Gary Kirckof's Cascading Logic, which is small but pricey. Also, check out the Automation Primer site ( http://www.automationprimer.com ) for an idea of real world automation. -- There can be political reasons, too; for example, I've heard at many union companies, the electricians can only use ladder logic, but not a higher level language such as C (because of union rules). -- I'm happy I can do most of my development in .NET (VB.NET and C# - I'm tempted to use F#). Ladder logic can be done well, but it's easy to create spaghetti code. A hard real time high level scripting language would be wonderful.... --Tony On Fri, Jan 4, 2013 at 9:10 AM, Mike King <[hidden email]> wrote:
I'm glad to hear that "real" programmers are using PLCs because I have a PLC based project on my to-do list. I have read a book on the topic and it was so painful. The concepts are so simple but their explanations are so complex. I can understand from a historical perceptive how ladder logic came about, but in modern times, I cannot understand why people try to explain the programming primitives in terms of coils and switches. I feel like I'm missing something basic. I think I remember reading that ladder logic is a "hard" real-time programming language. I know there are other languages for PLCs but ladder logic seems to be the dominant one. Do "real" programmers use ladder logic?
On Sun, Dec 30, 2012 at 12:47 PM, Dado Sutter <[hidden email]> wrote:
On Sat, Dec 29, 2012 at 11:59 PM, Quentin <[hidden email]> wrote:
I have to clean up the code first before I release it into the public domain.
Cool!
No hurry.
Thanksssssss
I also have to complete the manual as there are many new features that have been added. The standard Modbus functions work as per the specification, however I added more message types to allow one to use this over a GPRS/3G modem.
Sounds nice! I've never used Modbus over the air.
For example, reporting on exception. This saves on bandwidth and the master does not have to poll all the units in the field continuously.
Very cool. Thanks for sharing. It seems like it deserves to become a specific optional module for eLua apps in the future.
Quentin Best wishes
Dado
On 2012/12/30 02:27 AM, Dado Sutter wrote: Hi, On Sun, Dec 2, 2012 at 1:55 PM, Quentin Barry <[hidden email]> wrote:
Hello Tim
Very interesting - the Classic Ladder bit.
I have a substantial implementation of the Modbus RTU protocol on my ARM9 board.
Is your Modbus code open source and available on an online repo?
Thanks for the link.
Quentin
Thanksssssssss
Dado
Here is a low cost board...
JeroenDS made amazing PLC project with iMX233-OLinuXino: http://leachy.homeip.net/olinuxino/
From: Quentin Barry <[hidden email]>
To: eLua Users and Development List (www.eluaproject.net) <[hidden email]> Sent: Sunday, December 2, 2012 9:50 AM Subject: [eLua-dev] ARM9 Embedded PLC Hi Tom
I was thinking of using the LM3S6965. I think that it has ample resources to suit my requirements.
It comes with 64 KB of bit-banded SRAM and 256 KB of flash memory. It has the MAC and PHY built into the IC. All that one requires is the RJ45 connector. I think that this device was targeted for Ethernet to Serial bridges. There are detailed design and application notes on their website.
Without a doubt one cannot deny that ST has the lion's share of the Cortex market. I do use their devices regularly too. However there are certain niche markets that other vendors target.
Stellaris with their LM3S6965 for Ethernet
NXP and Energy Micro for Graphics Displays - EmWin is a free download for these devices.
Si-Labs have a highly configurable patented dual crossbar technology to define pinouts.
I guess it all boils down to what the end application is.
Regards
Quentin
That's OK, Quentin.
A new look at an existing product line is always welcomed.
Being that you are a hardware person, take a look at the W7200 in the Wiznet site.
Notice that it uses STM32 IP with 128K Flash and 20K RAM. If you can come up with the equivalent using Stellaris IP with 512 K Flash (or better) and 64K RAM (or better), I can use that.
On Sun, Dec 2, 2012 at 1:26 AM, Quentin Barry <[hidden email]> wrote:
Thanks for the link.
The issue here is that I am a hardware / embedded engineer. I don't want to buy someone else's solution - but want to design my own. You may call it re-inventing the wheel, but that is OK. I am planning on using one of the Luminary Micro / Stellaris Cortex M3 devices to implement the Ethernet to Serial bridge. I could simply have used a Tibbo module if I was so inclined.
I have taken a look at the Microchip offerings but then you are tied in to their compiler and development environment. With the Stellaris solution everything is open source. One also has the flexibility to change and add things as well. For example I could add a CC1125 to the Cortex as well and then I would have an Ethernet and an ISM band device in one.
Quentin
Take a look at:
On Thu, Nov 29, 2012 at 7:53 AM, Quentin Barry <[hidden email]> wrote:
That would be great. I also have quite a hectic schedule for approximately the next 2 weeks and then I will be free. Being your own boss can kill you sometimes.
I have all the PDF files for the PLC - where can I deposit them? If people are happy with what they see then I will upload all the Gerber files a bit later. All I need is a bit of guidance here on where to deposit the files without creating confusion. I guess a bit of moderator support is required at this junction.
Quentin.
I would be interested and willing to help you get eLua running on your PLC board. I am unlikely to have much time for the next two weeks due to a work project deliverable. After that I could spend some time on getting eLua running and working on some modules to interface to the various hardware peripherals.
I also may be interested in your Ethernet gateway board, as I have a few projects where I plan on using eLua and will need Ethernet.
-djd
On Nov 28, 2012, at 11:58 PM, Quentin Barry wrote:
Hello All
If I was to design an Ethernet to serial gateway would there be any interest? Basically it would accept 10/100 Mb Ethernet and convert it to serial or SPI and vica-versa.
I would make all the gerber files available. I think that a modular method is perhaps the best route to follow as main processor is then not burdened with these other tasks. All it has to do is to capture packets on the Serial or SPI layer, process them and reply if necessary.
I also have a complete design for a small PLC using the STR912FAW47. It has:
Most of the low level drivers are written in C and have been battled tested. This is revision 2 of the board, so there are a few hardware changes and some of the drivers have to change, or still have to be written. Everything is interrupt driven.
I have not yet had the time to implement eLua on it, but there is a port available for this CPU.
Is anyone interested in working with me to get this up and going with eLua?
Quentin_______________________________________________
eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev --
Douglas Davenport
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev -- Tom Freund Dig.y.SoL (TM) "Systems overseeing public and private
infrastructure"
Voice - 860-232-1614 Skype ID - digysol _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev -- Tom Freund Dig.y.SoL (TM) "Systems overseeing public and private
infrastructure"
Voice -<A href="tel:860-232-1614"> 860-232-1614 Skype ID - digysol _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list[hidden email]https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Thank you Quentin for sharing your thoughts on this topic! _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Quentin Barry
More off-topic comments below; it's always fun to learn about different areas (my experience is mostly on high precision machines with servo motors).
To get sort-of back on topic, I do think Lua/eLua would make an excellent language for industrial automation. I don't think we could convert many PLC users, but I do like the idea of an "eLua PLC" (eLua running on a platform with PLC-style I/O, e.g. 24V isolated inputs and outputs, not 5V or 3.3V). Many industrial controllers (including robot controllers) already use the combination of interpreted higher level language that calls low level routines. For the bulk of my code, ladder logic simply wouldn't work, but Lua would be fine (I've used Python in the past), but for political reasons I have to use .NET. On Sat, Jan 5, 2013 at 3:52 AM, Quentin Barry <[hidden email]> wrote:
Ladder is easy to use and read as long as your problem easily fits into combinatorial logic. If you start needing data manipulation, to interface with serial barcode reader protocols, or a lot of other areas it sucks. If you want to do servo motion control, a motion controller is often a better approach (we've done PLC motion control and it wasn't pretty; PLCOpen looks better but I haven't used it).
Fixed cycle time is pretty common; even my low end Panasonics can do that. However, I'm not sure how necessary it is now; I'm pretty sure many PLCs have built-in PID instructions. If you need high speed PID loops without writing your own code, use a motion controller (1->20Khz is pretty common; I've seen one rated at 200KHz).
We used Mitsubishi a long time ago, and back then they were well known for crappy software and bad documentation (I found several errors without even trying) - hopefully it's better now. Standard Ethernet with TCP/IP and normal switches is not deterministic, although lightly loaded systems might work well. BTW, Mitsubishi's CC-Link IE uses Gigabit Ethernet physical layer, but it is not standard (e.g. uses token passing).
IEC61131 functions and function calls are still bad compared to a normal language, even C. I've dealt with hard-wired (relay) circuits for such things as standby pump control and reactor rod insertion interlocks. There's still a place for them (I don't fully trust software). If your logic is mainly as you describe, then ladder logic sounds like a decent match.
We don't use SCADA; we use a PC for HMI, and our customers don't allow outside access.
Typically, modules are isolated but the individual I/O lines aren't isolated from each other. I'll agree that PLC's are pretty robust; I've only had 1 fail, and I've shorted Panasonic PLC's more than once (24V power to ground).
PLC software costs depend more on the vendor than on IEC611 compliance, e.g. Allen Bradley is very expensive. However, Panasonic's FPWinPro is reasonable, and there's a free, code-size limited version. PLC prices range from <$100 (Automation Direct) to $3K or more. Yes, an industrial PC (e.g. Kontron, Wago, Phoenix, Beckhoff, etc DIN rail mounted with no cooling fan or a x86-equipped PAC from Omron) can replace a PLC, although a lot of times they're still running ladder logic -- and they're a lot more expensive than a Dell.
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: [SPAM] Re: [SPAM] Re: [SPAM] Re: ARM9 Embedded PLC
|
|
On 12 January 2013 02:03, Tony <[hidden email]> wrote:
> but I do like the idea of an "eLua PLC" (eLua running on a platform > with PLC-style I/O, e.g. 24V isolated inputs and outputs, not 5V or 3.3V). That's relatively easy to do with a Mizar32 and its prototyping board by wiring op-amps to its 66 GPIOs and finding 24V somewhere. Personally I'd like to have luasockets, Lua File System and so on as interfaces, so as to be able to use all the libraries that need them. For some, such as luasockets, an implementation should be possible in Lua on the existing net.*() interface. M M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |