Post by thread:PLC help

Truncated match.
PICList Thread
'PLC help'
2003\01\23@083638 by Orbit Communications

Does anyone have an example of PIC source for PIC used as PLC ? Or info on decoding and executing the ladder logic source. Thanks in advance David Huisman -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\23@101612 by Spehro Pefhany

At 12:32 AM 1/24/03 +1100, you wrote: >Does anyone have an example of PIC source for PIC used as PLC ? >Or info on decoding and executing the ladder logic source. No example code, but I've done this sort of thing before. PICs are not the best for *P*LCs because of the architecture, 8051-derivatives are often used. Of course, a PIC can be used, but there will be a speed penalty. You'd have to parse the ladder logic commands and generate tokens, which would be interpreted by subroutines in the PIC. The first part perhaps can be done on a PC. Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" spam_OUTspeffTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\23@112541 by Wouter van Ooijen

> You'd have to parse the ladder > logic commands and generate tokens, which would be interpreted > by subroutines in the PIC. The first part perhaps can be done > on a PC. when you parse the ladder logic anyway, why not generate HLL or even asm directly from it? Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\23@144249 by Dwayne Reid

At 05:25 PM 1/23/03 +0100, Wouter van Ooijen wrote: > > You'd have to parse the ladder > > logic commands and generate tokens, which would be interpreted > > by subroutines in the PIC. The first part perhaps can be done > > on a PC. > >when you parse the ladder logic anyway, why not generate HLL or even asm >directly from it? The few times that I have done PLC type code on a PIC, I implemented it as a series of state machines. All the translation between ladder logic and asm code was done by hand, though. If I had to do it again, I'd take a close look at Z-mech to see how much easier it would make the job. dwayne -- Dwayne Reid <.....dwaynerKILLspam@spam@planet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 18 years of Engineering Innovation (1984 - 2002) .-. .-. .-. .-. .-. .-. .-. .-. .-. .- `-' `-' `-' `-' `-' `-' `-' `-' `-' Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\23@151639 by Peter L. Peres

On Fri, 24 Jan 2003, Orbit Communications wrote: *>Does anyone have an example of PIC source for PIC used as PLC ? *>Or info on decoding and executing the ladder logic source. Microchip has an application note for this. I don't have an example but when done by hand you can proceed following this outline (which I have used): Determine the number of rungs. Write a logical equation for each rung. Write code for each rung, to implement its equation, in C or assembly or whatever. Make a 'main' code that calls (or inlines) the code of each rung and then loops forever. Like forever: call Srung1 call Srung2 ... call SrungN call Delay goto forever The Delay may be necessary or not, and you could put some debugging code there (what I did, using bit banged RS232 at 9600 Bauds to send certain variables). This code does not support 'subroutines' and other such things. You can replace the Delay with a spinlock around a flag that is set by a constant time ISR. Then you can also implement real time delays etc. A timer register is a variable that is decremented by the timer isr until zero, then the timer isr sets a flag that is used (and cleared!) by the relevant rung code. You will need to calculate latency and other things (like cpu load) carefully. PLC controlled hardware has a way to fail spectacularly when controlled with improper sequences. hope this helps, Peter -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\23@193241 by Spehro Pefhany

At 05:25 PM 1/23/03 +0100, you wrote: > > You'd have to parse the ladder > > logic commands and generate tokens, which would be interpreted > > by subroutines in the PIC. The first part perhaps can be done > > on a PC. > >when you parse the ladder logic anyway, why not generate HLL or even asm >directly from it? Yes, you're right, it's possible with newer PICs that can write to their own code memory. I'm distinguishing between a PLC (which is programmable by the user) and just simple boolean logic with a fixed program. Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" speffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\24@145236 by Bob Ammerman

I have developed a system for one of my customers which works as follows: 1: Draw a ladder diagram using the schematic editor in Eagle. 2: Generate PARTLIST and NETLIST files from the Eagle drawing. 3: Parse the PARTLIST and NETLIST to 'compile' the ladder diagram into an intermediate 'P-Code' like language. 4: Load the 'P-Code' into an x86 based embedded system. 5: JIT (just-in-time) compile the P-Code to very efficient threaded code. 6: Interpret the threaded code. This system is able to run at millions of rungs per seccond. The final interpreter is highly optimized (although written in C++ !) and executes an average of less than 10 x86 instructions for each I've often thought that I could replace step 5 with a P-Code to PIC assembly converter. Unfortunately, I cannot share any of the details/code of this system as it was a work done for hire. Bob Ammerman RAm Systems. {Original Message removed}

2003\01\24@150250 by Spehro Pefhany

At 02:51 PM 1/24/03 -0500, you wrote: >I have developed a system for one of my customers which works as follows: <snip> Very clever- using Eagle schematic editor as a visual front end! Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" .....speffKILLspam.....interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

2003\01\24@161144 by Bob Ammerman

> At 02:51 PM 1/24/03 -0500, you wrote: > >I have developed a system for one of my customers which works as follows: > > <snip> > > Very clever- using Eagle schematic editor as a visual front end! > Thank you. My customer was *very* pleased not to have to develop that part. And the neat thing is that the same drawing serves as input to the compiler and the documentation for the users of the system. Bob Ammerman RAm Systems -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

2003\01\24@162436 by Wouter van Ooijen

> 1: Draw a ladder diagram using the schematic editor in Eagle. I love that kind of (mis) use. Seems like an irresistible project should I ever have more time than work at hand... I did a little ladder programming in a previous life, but the memory has faded. Any good reference texts on ladder programming, and especially on the various elements that are used? Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

2003\01\24@163923 by Spehro Pefhany

At 10:22 PM 1/24/03 +0100, you wrote: >I did a little ladder programming in a previous life, but the memory has >faded. Any good reference texts on ladder programming, and especially on >the various elements that are used? I've got some expensive books that I bought when I did a project that implemented it, but you can download the manuals from any of the PLC manufacturers and be off and running. Suggest one of the smaller micro-PLCs, the big ones are closer to industrial computers with lots of complexity. If you want to be totally cool, you can implement IEC 1131-6. Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" EraseMEspeffspam_OUTTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

2003\01\24@165902 by Mario Antonio Amaral

----- Original Message ----- From: "Bob Ammerman" <rammermanspam_OUTADELPHIA.NET> To: <@spam@PICLISTKILLspamMITVMA.MIT.EDU> Sent: Friday, January 24, 2003 5:51 PM Subject: Re: PLC help {Quote hidden}> I have developed a system for one of my customers which works as follows: > > 1: Draw a ladder diagram using the schematic editor in Eagle. > > 2: Generate PARTLIST and NETLIST files from the Eagle drawing. > > 3: Parse the PARTLIST and NETLIST to 'compile' the ladder diagram into an > intermediate 'P-Code' like language. > > 4: Load the 'P-Code' into an x86 based embedded system. > > 5: JIT (just-in-time) compile the P-Code to very efficient threaded code. > > 6: Interpret the threaded code. > > This system is able to run at millions of rungs per seccond. The final > interpreter is highly optimized (although written in C++ !) and executes an > average of less than 10 x86 instructions for each > > I've often thought that I could replace step 5 with a P-Code to PIC assembly {Quote hidden}> converter. > > Unfortunately, I cannot share any of the details/code of this system as it > was a work done for hire. > > Bob Ammerman > RAm Systems. > > > ----- Original Message ----- > From: "Spehro Pefhany" <KILLspamspeffKILLspamINTERLOG.COM> > To: <RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU> > Sent: Thursday, January 23, 2003 10:15 AM > Subject: Re: PLC help > > > > At 12:32 AM 1/24/03 +1100, you wrote: > > >Does anyone have an example of PIC source for PIC used as PLC ? > > >Or info on decoding and executing the ladder logic source. > > > > No example code, but I've done this sort of thing before. > > PICs are not the best for *P*LCs because of the architecture, > > 8051-derivatives are often used. Of course, a PIC can be used, > > but there will be a speed penalty. You'd have to parse the ladder > > logic commands and generate tokens, which would be interpreted > > by subroutines in the PIC. The first part perhaps can be done > > on a PC. > > > > Best regards, > > > > Spehro Pefhany --"it's the network..." "The Journey is the > reward" > > spamBeGonespeffspamBeGoneinterlog.com Info for manufacturers: > http://www.trexon.com > > Embedded software/hardware/analog Info for designers: > http://www.speff.com > > > > -- > > http://www.piclist.com hint: The list server can filter out subtopics > > (like ads or off topics) for you. See http://www.piclist.com/#topics > > > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

2003\01\24@182211 by William Chops Westfield

> I have developed a system for one of my customers which works as follows: > > 1: Draw a ladder diagram using the schematic editor in Eagle. > > 2: Generate PARTLIST and NETLIST files from the Eagle drawing. > > 3: Parse the PARTLIST and NETLIST to 'compile' the ladder diagram into an > intermediate 'P-Code' like language. That's cute. Do you have to become an Eagle "distributer", or do you just insist that the customer buy a copy of at least the schematic editor? BillW -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

2003\01\24@185911 by Orbit Communications

We will be developing our own GUI so that license/cost issues are minimized. The function now is developing an efficient and simple strategy for tokenising the Ladder logic statements and executing them from external serial flash memory. The other option was to simply have a library of functions in the PIC as an "operating system" and write some pseudo-code to represent calls to these functions with parameters. Does anyone know where there is information that describes the output of a compiled ladder logic program ? Any other ideas ? Kind Regards David Huisman (CEO) ----------------------------------------------------------------------- ORBIT COMMUNICATIONS - Wireless Solutions that Work (Telemetry, Control, Monitoring, Security, HVAC ...) Website : http://www.orbitcoms.com PO Box 4474 Lakehaven NSW 2259, AUSTRALIA Phone: 61-2-4393-3627 Fax : 61-2-4393-3685 Mobile: 61-413-715-986 {Original Message removed}

2003\01\24@191608 by James Caska

> Any other ideas ? Pending your time frame, if you are interested in developing a java based solution I may be interested in assisting you a) To use Virtual Breadboard's openVBB framework as the (free) schematic editor of the ladder logic diagrams b) To autogenerate java code or even better - an embedlet object heirachy from the ladder logic diagrams for execution on the new (very very soon ) to be released uVM PIC Java processor c) Developing necessary java packages to support the execution of PLC style code in the com.muvium framework References http://www.virtualbreadboard.com http://www.muvium.com http://sourceforge.net/projects/embedlets/ Jump onto the embedlets list and repost this.. it is VERY similar and compatible with some of the work we are thinking about over there. Ted Kosan in particular would be interested in talking about PLC applications of the embedlets concept. I have posted this to the embedets list as a lead in.. Just some ideas ;-) Regards, James Caska > {Original Message removed}

2003\01\24@211822 by Bob Ammerman

The customer licenses Eagle themselves. Unfortunately they have to get at least the schematic and board programs, but not the autorouter. Since they don't care about board size and layer limits it only costs them about $400.00 per seat. Bob Ammerman {Original Message removed}

2003\01\25@005459 by James Caska

> 1: Draw a ladder diagram using the schematic editor in Eagle. > > 2: Generate PARTLIST and NETLIST files from the Eagle drawing. > > 3: Parse the PARTLIST and NETLIST to 'compile' the ladder diagram into > an > > > intermediate 'P-Code' like language. Do you have a specification for the NETLIST 'compiler' and the P-CODE language? Is this work available for free/licence/don't-know-its-not-mine? James > {Original Message removed}

2003\01\25@092417 by Bob Ammerman

I designed the P-Code language and wrote the netlist compiler for a customer as a work for hire. Therefore it belongs to them, not me. This was developed for their internal use. They are not in the business of licensing software, and I am certain they would not be interested in doing so, sorry! I do think that it would be ok for me to expound in a little more detail on how all this works. I'll try to find the time to post a message describing it in the reasonable future. Bob Ammerman RAm Systems ----- Original Message ----- From: "James Caska" <TakeThisOuTcaskaEraseMEspam_OUTVIRTUALBREADBOARD.COM> To: <RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU> Sent: Saturday, January 25, 2003 12:21 AM Subject: Re: PLC help {Quote hidden}> > 1: Draw a ladder diagram using the schematic editor in Eagle. > > > > 2: Generate PARTLIST and NETLIST files from the Eagle drawing. > > > > 3: Parse the PARTLIST and NETLIST to 'compile' the ladder diagram into > > an > > > > intermediate 'P-Code' like language. > > Do you have a specification for the NETLIST 'compiler' and the P-CODE > language? > Is this work available for free/licence/don't-know-its-not-mine? > > James > > > > {Original Message removed}

2003\01\26@005351 by Sergio Masci

Orbit Communications wrote: > We will be developing our own GUI so that license/cost issues are minimized. > > The function now is developing an efficient and simple strategy for > tokenising the Ladder logic statements and executing them from external > serial flash memory. > > The other option was to simply have a library of functions in the PIC as an {Quote hidden}> "operating system" and write some pseudo-code to represent calls to these > functions with parameters. > > Does anyone know where there is information that describes the output of a > compiled ladder logic program ? > > Any other ideas ? > > Kind Regards > > David Huisman (CEO) There is a system called IPAD-Pro that is specifically designed for building this kind of tool. It will allow you to build a tool that has a visual programming interface, which can generate anything you like directly from diagrams (no need for an external compiler). You add intelligence to objects a user places on his diagrams and when the user hits the generate button, all the objects play their part in generating the code. The on screen objects can indicate an error directly on the diagram, even take part in debugging and testing the tool as you build it AND debugging and testing the system your client builds from your tool. You can even use IPAD-Pro to build support tools that directly integrate into the system that your clients build (such as virtual hardware mimics or glass consoles). A complete solution from distributed controllers to co-ordinating hub. ZMech was built using IPAD-Pro. ZMech is a sophisticated state machine development tool. A version of this tool is available that generates directly executable PIC machine code. The enterprise edition of ZMech allows you to tailor ZMech to your own specific needs. ZMech actually allows the user to interactively debug state machines by running them against the diagram the user entered. The generated state machine code is executed, not an abstract table corresponding to the state machine. All code added by the user is actually executed and participates in the operation of the state machine, whether it is Pentium C++ code or PIC assembler. The XEBOT tool (itself built using IPAD-Pro) is a visual programming interface that interacts directly with the IPAD-Pro core and allows you to build user interface components (GUI) that directly interact with the tools that you produce. It allows you to build dialogs, forms, virtual mimics etc using the Visual Basic / C++ style of drag and drop programming. XCASM is a very powerful meta assembler with sophisticated macro capabilities. With it you can generate executable machine code for any processor you like including your own proprietary FPGA implemented CPU. XCASM provides high level simulation capabilities which interface through the XCSIM simulator to the IPAD-Pro core. In other words, the tools you build using XCASM can embed high level simulation code directly in the assembler source they generate. One benefit of this is that you can design a suite of test functions that interact with the generated code to validate it. No need to provide a user manual with complex sequences of instructions to trouble shoot generated code. More information on IPAD-Pro, ZMech, XEBOT, XCASM, XCSIM and XCSB (structured PIC BASIC compiler currently being developed for the PIC and based on XCASM) can be found at: http://www.xcprod.com Regards Sergio Masci -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu>

2003\01\27@091350 by Micro Eng

First off...I've been doing PLC and ladder logic stuff for about 20 years. Unless you have a buring desire to do this for fun, the product for a small market might not be worth it, when you can buy all the pieces for what it might cost to develop your own. For a specific use controller, which is what PIC's are great for, then it makes sense to build a board, etc but write the code in C or assembly since it is for target use. Now, for PLC applications, the only reason to write ladder logic is legacy. In other words, thats the way its always been done, and the control engineers understand it (maybe some don't relize its a throwback to real ladder logic of using relays and timers) so why mess with it? To get back to the subject at hand, there is a company called Direct Automation that sells the stuff pretty darn cheap, because its thier brand, albiet it it probably a japanese remark, but you aren't paying the price for a Siemens or AB unit. Of course, some outfits demand an AB unit, because of the name associated with it. I've developed using AB software, Rockwell, GE, Siemens, TI and a few other off brand things, and they are all about the same. Just my .02 worth _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\01\27@150637 by Orbit Communications

I appreciate your comments but we are not wanting to develop a PLC. We are developing a specific product that will enhance our Wireless connectivity products. It will incorporate many functions not available in a PLC. We are interested in the mechanics of how PLC logic is presented to the controller in a typical PLC but have no intention of reinventing an existing product. Kind Regards David Huisman (CEO) ----------------------------------------------------------------------- ORBIT COMMUNICATIONS - Wireless Solutions that Work (Telemetry, Control, Monitoring, Security, HVAC ...) Website : http://www.orbitcoms.com PO Box 4474 Lakehaven NSW 2259, AUSTRALIA Phone: 61-2-4393-3627 Fax : 61-2-4393-3685 Mobile: 61-413-715-986 {Original Message removed}

2003\01\27@152336 by Sid Weaver

In a message dated 01/27/2003 15:07:04 Eastern Standard Time, EraseMEinfoORBITCOMS.COM writes: > We are interested in the mechanics of how PLC logic is presented to the > controller in a typical PLC but have no intention of reinventing an existing > product. > > Kind Regards > > Dvid, visit http://www.plcs.net. They have a wealth of infomation on PLC logic sysmbols and interpretation. Sid Weaver W4EKQ Port Richey, FL -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\01\27@190128 by James Caska

Again the embedlets specification is ALL about this, ie how to plug wide-fan java enabled devices into backend J2EE databases. Example wide-fan scenario we are working on http://crusher.ssu.portsmouth.oh.us/~tkosan/java/embeddedjavascenario/ Again I encourage you join the email list just to listen in on the emerging spec if you have not already done so ;-) http://sourceforge.net/projects/embedlets/ Regards, James Caska http://www.muvium.com 'Java Bred for Embedded' > {Original Message removed}

2003\01\28@022850 by Orbit Communications

James, So we can plug this Java based application into our VB.Net code ? Then we can extract text from the objects to form a Logic statements that we can integrate into our C based application in the PIC ? Kind Regards David Huisman (CEO) ----------------------------------------------------------------------- ORBIT COMMUNICATIONS - Wireless Solutions that Work (Telemetry, Control, Monitoring, Security, HVAC ...) Website : http://www.orbitcoms.com PO Box 4474 Lakehaven NSW 2259, AUSTRALIA Phone: 61-2-4393-3627 Fax : 61-2-4393-3685 Mobile: 61-413-715-986 ----- Original Message ----- From: "James Caska" <RemoveMEcaskaEraseMEEraseMEVIRTUALBREADBOARD.COM> To: <RemoveMEPICLISTspam_OUTKILLspamMITVMA.MIT.EDU> Sent: Tuesday, January 28, 2003 11:05 AM Subject: Re: PLC help > Again the embedlets specification is ALL about this, ie how to plug wide-fan > java enabled devices into backend J2EE databases. > > Example wide-fan scenario we are working on > > http://crusher.ssu.portsmouth.oh.us/~tkosan/java/embeddedjavascenario/ > > Again I encourage you join the email list just to listen in on the emerging > spec if you have not already done so ;-) > > http://sourceforge.net/projects/embedlets/ > > Regards, > James Caska > http://www.muvium.com > 'Java Bred for Embedded' > > > > {Original Message removed}

2003\01\28@070537 by James Caska

Hi David, > So we can plug this Java based application into our VB.Net code ? Embedlets is still in its infancy, but yes, Embedlets are about plugging networked embedded applications back into VB.Net and J2EE backends in a seamless and object orientated fashion. Embedlets is at this stage an Open Source Experts group forging a specification which we hope to build a standard and reference implementation upon. That standard then creates opportunities for commericial adopters like ORBIT COMMUNICATIONS , which is a wireless connectivity company is bang on the 'wide-fan' vision of the Embedlets target application. > Then we can extract text from the objects to form a Logic > statements that we > can integrate into our C based application in the PIC ? The embedlets concept is a little more ambitious than this. Using the PLC analogy which is where this began, PLC logic can be considered as a subset of the Embedlets specification. In this type of application, the components of the PLC ie Counters and Relays and Comparitors etc, are all Embedlet's and the Ladder logic is like the Embedlet connectivity schema and the Embedlet container is where all these Embedlets execute which is a bit like the PLC Looping Runtime. It's alot to take in at once, but basically the idea is to instead of extract strings and implement some sort of interpreter in C' you serialise the object tree representing the PLC Embedlet application and upload it over the internet into the Java Enabled Device implementing the Embedlet Container which as a minimal platform will be the muvium uVM-877A which is a PIC16F877A Java Enabled device. Regards, James Caska http://www.muvium.com 'Java Bred for Embedded' > {Original Message removed}

2003\01\28@073315 by Orbit Communications

James, Thanks for the info. I will keep reference to it for further study and it may come in useful for future projects. We are working on a mobile information network that may be able to take advantage of a technology such as you mentioned. As for the project at hand, we do not intend changing our hardware for this application. We currently implement both PIC16F876 and PIC18F6720. The programming will not be required over internet, users simply plug the wireless controller device into the PC via serial port or USB and upload new code as they make their own changes. Kind Regards David Huisman (CEO) ----------------------------------------------------------------------- ORBIT COMMUNICATIONS - Wireless Solutions that Work (Telemetry, Control, Monitoring, Security, HVAC ...) Website : http://www.orbitcoms.com PO Box 4474 Lakehaven NSW 2259, AUSTRALIA Phone: 61-2-4393-3627 Fax : 61-2-4393-3685 Mobile: 61-413-715-986 ----- Original Message ----- From: "James Caska" <RemoveMEcaskaTakeThisOuTspamVIRTUALBREADBOARD.COM> To: <EraseMEPICLISTspamspamBeGoneMITVMA.MIT.EDU> Sent: Tuesday, January 28, 2003 11:08 PM Subject: Re: PLC help > Hi David, > > > So we can plug this Java based application into our VB.Net code ? > > Embedlets is still in its infancy, but yes, Embedlets are about plugging > networked embedded applications back into VB.Net and J2EE backends in a > seamless and object orientated fashion. Embedlets is at this stage an Open > Source Experts group forging a specification which we hope to build a > standard and reference implementation upon. That standard then creates > opportunities for commericial adopters like ORBIT COMMUNICATIONS , which is > a wireless connectivity company is bang on the 'wide-fan' vision of the > Embedlets target application. > > > Then we can extract text from the objects to form a Logic > > statements that we > > can integrate into our C based application in the PIC ? > > The embedlets concept is a little more ambitious than this. Using the PLC > analogy which is where this began, PLC logic can be considered as a subset > of the Embedlets specification. In this type of application, the components > of the PLC ie Counters and Relays and Comparitors etc, are all Embedlet's > and the Ladder logic is like the Embedlet connectivity schema and the > Embedlet container is where all these Embedlets execute which is a bit like > the PLC Looping Runtime. > > It's alot to take in at once, but basically the idea is to instead of > extract strings and implement some sort of interpreter in C' you serialise > the object tree representing the PLC Embedlet application and upload it over {Quote hidden}> the internet into the Java Enabled Device implementing the Embedlet > Container which as a minimal platform will be the muvium uVM-877A which is a > PIC16F877A Java Enabled device. > > > Regards, > James Caska > http://www.muvium.com > 'Java Bred for Embedded' > > > > > > > {Original Message removed}

2003\01\28@094850 by James Caska

David , > Thanks for the info. I will keep reference to it for further study and it > may come in useful for future projects. We are working on a mobile > information network that may be able to take advantage of a > technology such > as you mentioned. Great. Hope to see you on the embedlets list asking tough questions down the track ;-) > As for the project at hand, we do not intend changing our > hardware for this > application. We currently implement both PIC16F876 and PIC18F6720. Well, this was always going to depend on how committed you already were to your current pathway and product. But for future products as you say it might be more compelling. > The programming will not be required over internet, users simply plug the > wireless controller device into the PC via serial port or USB and > upload new > code as they make their own changes. Of course the 'internet' doesn't mean it has to be remote. It can be as simple as plugging in a serial cable and using SLIP and a direct connection to access the device. Who knows you might want to have a Browser user interface to your wireless device or to allow your users to use java as the programming language for the controller. Again all nice thoughts for future products. James Caska http://www.muvium.com 'Java Bred for Embedded' > {Original Message removed}

2003\01\28@104816 by Micro Eng

whew...good. I was hoping you aren't just trying to make a better mousetrap. I look at how a PLC works in the fashion that its an interprative language, in that each 'rung' is analyzed one at a time, so as the program grow, the scan time begins to take effect. In other words, if you have a critical function such as a sensor that must react immidiatly then you have to put it in several times thru the ladder rungs to ensure you capture the event. It will simply scan from the first rung to the last rung and then start over. A microcontroller can do something similar, in that you just run it in a loop and each set of lines in the code could represent a rung, setting flags and turning on outputs. Timers could be in the ISR. But as mentioned before, its the software interface that makes it ladder logic, so that the old timers can still program and debug I guess. Some packages are doing it more graphical, and then again the nextGen PLC's called SoftPLC that simply run on a standard PC with a bunch of I/O cards can be programmed in C. {Quote hidden}>From: Orbit Communications <RemoveMEinfoKILLspamORBITCOMS.COM> >Reply-To: pic microcontroller discussion list <PICLISTSTOPspamspam_OUTMITVMA.MIT.EDU> >To: spamBeGonePICLISTSTOPspamEraseMEMITVMA.MIT.EDU >Subject: Re: PLC help >Date: Tue, 28 Jan 2003 07:03:22 +1100 > >I appreciate your comments but we are not wanting to develop a PLC. We are >developing a specific product that will enhance our Wireless connectivity >products. It will incorporate many functions not available in a PLC. > >We are interested in the mechanics of how PLC logic is presented to the >controller in a typical PLC but have no intention of reinventing an >existing >product. > >Kind Regards > >David Huisman (CEO) >----------------------------------------------------------------------- >ORBIT COMMUNICATIONS - Wireless Solutions that Work >(Telemetry, Control, Monitoring, Security, HVAC ...) > >Website : http://www.orbitcoms.com >PO Box 4474 Lakehaven >NSW 2259, AUSTRALIA >Phone: 61-2-4393-3627 >Fax : 61-2-4393-3685 >Mobile: 61-413-715-986 >{Original Message removed}

2003\01\28@201818 by llile

> But as mentioned before, its the software interface that makes it ladder logic, so that the old timers can still program and debug I guess. Some packages are doing it more graphical, and then again the nextGen PLC's called SoftPLC that simply run on a standard PC with a bunch of I/O cards can be programmed in C. AARRGH. <pulls hair> Taking a heavy duty industrial strength PLC program, and making it run on a standard PC with internal interface cards, (IMHO) is like taking a go-cart to the indy 500. Yeah, it will run around the track, and when it works a PC will also run as fast as a PLC. But what about when it hangs? Can it run in a 35C plant floor? At 98% humidity? With dirty power, say an arc welder running next to it? With dust and dirt flying around? When the power blinks out, will it reboot under control? Yes you can solve all these issues, and by the time you have spent the money and time to solve them, you could have bought a "real" PLC and just bolted it to the wall. I keep having nightmares about projects where we shoehorned industrial control or A/D equipment into PCs. THe end of the project is always this: 1. Get the industrial controls and A/D outside of the PC box. All those internal cards are nothing but headaches. That's what serial comms or ethernet are for. 2. Get something more reliable than a standard windows PC to run critical processes. Even a refrigerator is a critical process. 3. Think about embedded control, PLC or some other dedicated item that has nothing to do except pay attention to our process. 4. THEN port the output data to a PC so the operator can look at pretty pictures of what was going on while his PC was down or paying attention to something else. Just my 2c worth. -- Lawrence Lile Micro Eng <KILLspammicro_engspamBeGoneHOTMAIL.COM> Sent by: pic microcontroller discussion list <EraseMEPICLISTEraseMEMITVMA.MIT.EDU> 01/28/2003 09:45 AM Please respond to pic microcontroller discussion list To: @spam@PICLIST@spam@spam_OUTMITVMA.MIT.EDU cc: Subject: Re: PLC help whew...good. I was hoping you aren't just trying to make a better mousetrap. I look at how a PLC works in the fashion that its an interprative language, in that each 'rung' is analyzed one at a time, so as the program grow, the scan time begins to take effect. In other words, if you have a critical function such as a sensor that must react immidiatly then you have to put it in several times thru the ladder rungs to ensure you capture the event. It will simply scan from the first rung to the last rung and then start over. A microcontroller can do something similar, in that you just run it in a loop and each set of lines in the code could represent a rung, setting flags and turning on outputs. Timers could be in the ISR. But as mentioned before, its the software interface that makes it ladder logic, so that the old timers can still program and debug I guess. Some packages are doing it more graphical, and then again the nextGen PLC's called SoftPLC that simply run on a standard PC with a bunch of I/O cards can be programmed in C. >From: Orbit Communications <spamBeGoneinfoKILLspamORBITCOMS.COM> >Reply-To: pic microcontroller discussion list <.....PICLISTspam_OUTMITVMA.MIT.EDU> >To: TakeThisOuTPICLIST.....TakeThisOuTMITVMA.MIT.EDU >Subject: Re: PLC help >Date: Tue, 28 Jan 2003 07:03:22 +1100 > >I appreciate your comments but we are not wanting to develop a PLC. We are {Quote hidden}>developing a specific product that will enhance our Wireless connectivity >products. It will incorporate many functions not available in a PLC. > >We are interested in the mechanics of how PLC logic is presented to the >controller in a typical PLC but have no intention of reinventing an >existing >product. > >Kind Regards > >David Huisman (CEO) >----------------------------------------------------------------------- >ORBIT COMMUNICATIONS - Wireless Solutions that Work >(Telemetry, Control, Monitoring, Security, HVAC ...) > >Website : http://www.orbitcoms.com >PO Box 4474 Lakehaven >NSW 2259, AUSTRALIA >Phone: 61-2-4393-3627 >Fax : 61-2-4393-3685 >Mobile: 61-413-715-986 >{Original Message removed}

2003\01\28@211037 by Bob Ammerman

> AARRGH. <pulls hair> Taking a heavy duty industrial strength PLC program, > and making it run on a standard PC with internal interface cards, (IMHO) > is like taking a go-cart to the indy 500. Actually, you don't have to use a standard PC. You can use an industrialized one if you are willing to pay for it, and they are _very_ robust. Check out the phone company standards of PCs in their switching offices. > Yeah, it will run around the > track, and when it works a PC will also run as fast as a PLC. A PC can generally blow the doors off a PLC. > But what > about when it hangs? Can it run in a 35C plant floor? At 98% humidity? > With dirty power, say an arc welder running next to it? With dust and > dirt flying around? When the power blinks out, will it reboot under > control? Yes you can solve all these issues, and by the time you have > spent the money and time to solve them, you could have bought a "real" PLC > and just bolted it to the wall. The 'right' way this is done today is to use a real-time kernel that runs on the physical hardware and supports WinNT/2000/XP on top of it. It turns out that the WinNT family is based on a Hardware Abstraction Layer, which can be supplied by the underlying real-time kernel. In general the 'realtime' portion of the system has limited functionality, but you can have very high bandwidth connectivity between it and the non-realtine components (eg: logging, user interface, whatever). -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\28@220320 by Josh Koffman

Is that why there are things like embedded XP? Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams Bob Ammerman wrote: > The 'right' way this is done today is to use a real-time kernel that runs on > the physical hardware and supports WinNT/2000/XP on top of it. It turns out > that the WinNT family is based on a Hardware Abstraction Layer, which can be > supplied by the underlying real-time kernel. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

2003\01\29@030819 by William Chops Westfield

> The 'right' way this is done today is to use a real-time kernel > that runs on the physical hardware and supports WinNT/2000/XP > on top of it. It turns out that the WinNT family is based on a > Hardware Abstraction Layer, which can be supplied by the > underlying real-time kernel. Is that why there are things like embedded XP? I don't think so. From what I say through of a uSoft presentation at some tradeshow, what microsoft is offering for their "embedded" toolset is a packaging product, designed to easilly build windows-xp images with small footprints for assorted "kiosk-like" environments. I'd be really pissed off at that concept, except that it probably makes an awful lot of sense for a lot of "embedded" applications. "embedded" is not at all the same thing as "real time." BillW PS: Ever go to mcDonalds while they were featuring PCs (with games) in their "play areas"? Now THERE is a design challenge for anyone. I don't think I ever saw it with a complete working keyboard, for instance, in spite of the fact that it seemed to get regular maintenance... Wow. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

2003\01\29@093210 by Micro Eng

And...that is why, in 20 years, I have yet to do any project with a PC based control system. As a supervisory system yes, but not as the actual controller. Its either a PLC or a design specific controller (the one I developed was a machine controller, human interface with 4 buttons, 2x20LCD, 6 AC inputs, 6 relay outputs, based on the '877 chip) for anything that needs a robust system. {Quote hidden}>From: TakeThisOuTllileKILLspamspamSALTONUSA.COM >Reply-To: pic microcontroller discussion list <.....PICLISTRemoveMEMITVMA.MIT.EDU> >To: RemoveMEPICLISTspamBeGoneMITVMA.MIT.EDU >Subject: Re: PLC help >Date: Tue, 28 Jan 2003 10:40:16 -0600 > > > But as mentioned >before, its the software interface that makes it ladder logic, so that the >old timers can still program and debug I guess. Some packages are doing >it >more graphical, and then again the nextGen PLC's called SoftPLC that >simply >run on a standard PC with a bunch of I/O cards can be programmed in C. > >AARRGH. <pulls hair> Taking a heavy duty industrial strength PLC program, >and making it run on a standard PC with internal interface cards, (IMHO) >is like taking a go-cart to the indy 500. Yeah, it will run around the >track, and when it works a PC will also run as fast as a PLC. But what >about when it hangs? Can it run in a 35C plant floor? At 98% humidity? >With dirty power, say an arc welder running next to it? With dust and >dirt flying around? When the power blinks out, will it reboot under >control? Yes you can solve all these issues, and by the time you have >spent the money and time to solve them, you could have bought a "real" PLC >and just bolted it to the wall. > >I keep having nightmares about projects where we shoehorned industrial >control or A/D equipment into PCs. THe end of the project is always this: > >1. Get the industrial controls and A/D outside of the PC box. All those >internal cards are nothing but headaches. That's what serial comms or >ethernet are for. > >2. Get something more reliable than a standard windows PC to run critical >processes. Even a refrigerator is a critical process. > >3. Think about embedded control, PLC or some other dedicated item that has >nothing to do except pay attention to our process. > >4. THEN port the output data to a PC so the operator can look at pretty >pictures of what was going on while his PC was down or paying attention to >something else. > >Just my 2c worth. > > >-- Lawrence Lile > > > > > >Micro Eng <spamBeGonemicro_eng@spam@spam_OUTHOTMAIL.COM> >Sent by: pic microcontroller discussion list <TakeThisOuTPICLISTspamMITVMA.MIT.EDU> >01/28/2003 09:45 AM >Please respond to pic microcontroller discussion list > > > To: PICLISTEraseMEMITVMA.MIT.EDU > cc: > Subject: Re: PLC help > > >whew...good. I was hoping you aren't just trying to make a better >mousetrap. > >I look at how a PLC works in the fashion that its an interprative >language, >in that each 'rung' is analyzed one at a time, so as the program grow, the >scan time begins to take effect. In other words, if you have a critical >function such as a sensor that must react immidiatly then you have to put >it >in several times thru the ladder rungs to ensure you capture the event. It >will simply scan from the first rung to the last rung and then start over. >A microcontroller can do something similar, in that you just run it in a >loop and each set of lines in the code could represent a rung, setting >flags >and turning on outputs. Timers could be in the ISR. But as mentioned >before, its the software interface that makes it ladder logic, so that the >old timers can still program and debug I guess. Some packages are doing >it >more graphical, and then again the nextGen PLC's called SoftPLC that >simply >run on a standard PC with a bunch of I/O cards can be programmed in C. > > > > > > > > >From: Orbit Communications <RemoveMEinfoEraseMEspam_OUTORBITCOMS.COM> > >Reply-To: pic microcontroller discussion list <@spam@PICLISTRemoveMEEraseMEMITVMA.MIT.EDU> > >To: EraseMEPICLIST@spam@MITVMA.MIT.EDU > >Subject: Re: PLC help > >Date: Tue, 28 Jan 2003 07:03:22 +1100 > > > >I appreciate your comments but we are not wanting to develop a PLC. We >are > >developing a specific product that will enhance our Wireless connectivity > >products. It will incorporate many functions not available in a PLC. > > > >We are interested in the mechanics of how PLC logic is presented to the > >controller in a typical PLC but have no intention of reinventing an > >existing > >product. > > > >Kind Regards > > > >David Huisman (CEO) > >----------------------------------------------------------------------- > >ORBIT COMMUNICATIONS - Wireless Solutions that Work > >(Telemetry, Control, Monitoring, Security, HVAC ...) > > > >Website : http://www.orbitcoms.com > >PO Box 4474 Lakehaven > >NSW 2259, AUSTRALIA > >Phone: 61-2-4393-3627 > >Fax : 61-2-4393-3685 > >Mobile: 61-413-715-986 > >{Original Message removed}

2003\01\30@015917 by Sergio Masci

----- Original Message ----- From: Bob Ammerman <@spam@rammermanspam_OUT.....ADELPHIA.NET> To: <spamBeGonePICLISTEraseMEMITVMA.MIT.EDU> Sent: Wednesday, January 29, 2003 1:46 AM Subject: Re: PLC help > > AARRGH. <pulls hair> Taking a heavy duty industrial strength PLC program, > > and making it run on a standard PC with internal interface cards, (IMHO) > > is like taking a go-cart to the indy 500. > > Actually, you don't have to use a standard PC. You can use an industrialized > one if you are willing to pay for it, and they are _very_ robust. Check out {Quote hidden}> the phone company standards of PCs in their switching offices. > > > Yeah, it will run around the > > track, and when it works a PC will also run as fast as a PLC. > > A PC can generally blow the doors off a PLC. > > > But what > > about when it hangs? Can it run in a 35C plant floor? At 98% humidity? > > With dirty power, say an arc welder running next to it? With dust and > > dirt flying around? When the power blinks out, will it reboot under > > control? Yes you can solve all these issues, and by the time you have > > spent the money and time to solve them, you could have bought a "real" PLC > > and just bolted it to the wall. > > The 'right' way this is done today is to use a real-time kernel that runs on > the physical hardware and supports WinNT/2000/XP on top of it. It turns out > that the WinNT family is based on a Hardware Abstraction Layer, which can be > supplied by the underlying real-time kernel. > > In general the 'realtime' portion of the system has limited functionality, > but you can have very high bandwidth connectivity between it and the > non-realtine components (eg: logging, user interface, whatever). Yep, my car can fly - if I wrap a cargo plane around it! Sorry I cringe at the thought of using M$ products for real time or embedded stuff. If you just want fancy graphics get a real realtime OS and stick the graphics on. <rant>Why is it that so many programmers want to be able to program without understanding how to program. Can't use make, can't use RCS, can't use ftp, can't even use dir!</rant> Regards Sergio -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...