Kind of wondering if should implement this in Micropython as the infrastructure is already there...
Would be concerned about it being too slow though... Unless actually compiled...
@Mickster , I totally agree. I'm not keen on Ladder myself, especially as math and string handling has encroached on the space. I only explore it as a simple option to put in place all the other parts of the system.
what are your thoughts of an ANSI interface that you could interface with just a terminal, perhaps on a laptop, and not toting extra VGA/keyboard?
I would like both, to be able to leave vga display and keyboard attached at some workstations, while others may be headless.
@Rayman said:
Kind of wondering if should implement this in Micropython as the infrastructure is already there..
NO ! NO ! NO !...
it is the ever shifting sands of the Python environment and libs that are the BANE OF MY EXISTENCE!
I want the very least between my system code and the hardware, and not have that infrastructure with the potential to screw up the critical clock-sensitive operations
The ansi VGA driver might be better at lower resolution (1024x768) but with 16x8 characters instead of 32x16.
This gives more text and might not have to implement scrolling for simple designs...
Also thinking that Micropython has a text editor already.
If a ".ld" file is going to be the input to whatever this is, can already edit this on P2...
This already works with both VGA and terminal...
Perhaps graphical editing can come later and start with just graphical inspection...
@Rayman
Also thinking that Micropython has a text editor already.
well, the more the merrier, I guess.
plenty of room for everyone. and, well, the code editor doesn't need precise real-time operation at all.
so, it might be a quick path to try thinggs out.
@Rayman said:
Kind of wondering if should implement this in Micropython as the infrastructure is already there..
NO ! NO ! NO !...
it is the ever shifting sands of the Python environment and libs that are the BANE OF MY EXISTENCE!
I want the very least between my system code and the hardware, and not have that infrastructure with the potential to screw up the critical clock-sensitive operations
Oberon is very interesting. Might have a play with it.
However, I don't see support for the PIO. I use the PIO for high-speed quadrature decode (4 encoders/Pico)
There will be various kludge methods, that stuff binary values for PIO, as already done in C.
Or, you can use an external PIO assembler and import a HEX or BIN array.
Has anyone done a PIO assembler / simulator ?
The problem, though is that it's always the perspective of an engineer, working on a program at his desk.....no consideration for the schmuck who is responsible for keeping that equipment churning-out product.
These guys don't get to program every day. Mention "uint" or "bool" or "float" and they will throw their hands up in the air and just give up until the outside support guy gets there, maybe in a couple of weeks.
I am talking about grabbing a USB keyboard and a VGA monitor, editing and instantly testing/running code, right on the Pico. No PC, no compiling, etc.
They need to be concentrating on what they need to do, not how to do it.
I can see your point, but a key advantage of Oberon + Pi PICO is an enthusiastic employee can easily learn at home, they do not need an expensive custom PLC.
There are always limits to the quick and dirty pathway of _ 'grabbing a USB keyboard and a VGA monitor, editing and instantly testing/running code'_ as you really do need to save and document the code at some point.
PC hosts that can edit code, search the web, access AI, and read PDFs and create documents as well as compile download and run, cover the bases nicely.
What they need is a good way to single step the target for debug.
The Venerable TurboPascal solved tight integration of Edit+Compile+Debug.
Oberon is very interesting. Might have a play with it.
However, I don't see support for the PIO. I use the PIO for high-speed quadrature decode (4 encoders/Pico)
There will be various kludge methods, that stuff binary values for PIO, as already done in C.
Or, you can use an external PIO assembler and import a HEX or BIN array.
Oberon looked interesting to me, too. Support for Pi Pico PIO is the first issue I checked for.
that seems to allow you to assemble using Adafruit_CircuitPython_PIOASM, then Emulate looping with a defined exit condition, giving your own custom format printf style reports.
Not very graphical, but good to archive and version track.
and this is a bit more graphical, using in.csv and out.csv files and readable in flow csv viewer
5.2.3 ALU Functions
The ALU is the main theatre for operations concerned with the execution of the Lilith M-code instructions.
To illustrate how the ALU would be involved in a sequence of M-code operations, we will
examine the execution of the hypothetical Modula 2 statement:
c := b + ap
where "b" is declared a local variable of type INTEGER, "c" is a global variable of the same type, and "ap"
is a global variable of type POINTER TO INTEGER.
The sequence of M-codes emitted by the compiler for this statement would be:
LL4 (* load the fourth local variable which is b *)
LG3 (* load the third global variable which is ap *)
LSWØ (* load word addressed by top of stack which is pointer value from ap *)
ADD (* add the two operands *)
SG5 (* store top of stack into fifth global variable which is c *)
Not sure how similar all that is, to the existing P2 Spin Byte code interpreter ?
@refaQtor said:
@Mickster , I totally agree. I'm not keen on Ladder myself, especially as math and string handling has encroached on the space. I only explore it as a simple option to put in place all the other parts of the system.
what are your thoughts of an ANSI interface that you could interface with just a terminal, perhaps on a laptop, and not toting extra VGA/keyboard?
I would like both, to be able to leave vga display and keyboard attached at some workstations, while others may be headless.
Sure:
Option 1) Connect KB, monitor, mouse directly
Option 2) Connect laptop/PC to USB and use something like Teraterm
This is what you get (color code can be switched on/off):
Option 3) Use the MMEdit IDE (Win or Linux):
Option 4) Use any editor and download with AUTOSAVE command.
There are always limits to the quick and dirty pathway of _ 'grabbing a USB keyboard and a VGA monitor, editing and instantly testing/running code'_ as you really do need to save and document the code at some point.
Sure. We have a filing system and WiFi that does file transfers
PC hosts that can edit code, search the web, access AI, and read PDFs and create documents as well as compile download and run, cover the bases nicely.
This is why an industrial Android tablet serves as my HMI. Inexpensive, ubiquitous, connectivity, memory, GPU, etc.
What they need is a good way to single step the target for debug.
Good point and not just single-stepping for code. A good program sequence is one where jumping to any location (sequence step) is possible. When a work-cell jams-up, we want to be able to resume without scrapping the valuable work-piece. Having to retract robots and reset every piece of process machinery is a major PITA.
The Venerable TurboPascal solved tight integration of Edit+Compile+Debug.
QuickBASIC 4.5 IDE; suspend, edit, continue. What a time-saver
QuickBASIC 4.5 IDE; suspend, edit, continue. What a time-saver
Glad that someone notices this. The way QB worked was just perfect, editing the code while it was paused, running testcode in between in this little console window..., F1 would give you detailed explanations for each command you point your cursor at.... Visual Basic does have that to some extend as far as i know but other languages lack that ability. Even in python, although you can use the console to call up routines and inspect variables, it's nowhere as fluid and convenient as QB was.
QuickBASIC 4.5 IDE; suspend, edit, continue. What a time-saver
Glad that someone notices this. The way QB worked was just perfect, editing the code while it was paused, running testcode in between in this little console window..., F1 would give you detailed explanations for each command you point your cursor at.... Visual Basic does have that to some extend as far as i know but other languages lack that ability. Even in python, although you can use the console to call up routines and inspect variables, it's nowhere as fluid and convenient as QB was.
The problem: Live machine and some things couldn't be suspended
The solution: Hijack and reprogram the PC's clock from 55ms to (I forget) a couple of ms(?) and compensate to preserve the time keeping.
Share memory (variables) with QB. Run the critical code in the ISR. Who says DOS doesn't do realtime?
not just editor, but a live HMI into the system, for complete state examination and control. Live debugging, step, step, step and watch the hardware respond. See the state of all the I/O live, or halt/step to twiddle the state of a pin or DAC or PWM or servo outputs.
Option 2) Connect laptop/PC to USB and use something like Teraterm
ALL OF THE ABOVE, though contstrained to ANSI text mode interface.
getting the live view/interaction can happen through some protocol and be displayed/controlled through a rich desktop interface... well, that is how all the proprietary systems work where you need to have loaded some compatible (maybe licensed) application on the version of OS that you have on your machine, etc. kinda all the stuff we're trying to get away from .
there is a nifty sort of HMI builder, even for the Propeller (that I keep forgetting the name) I used a year ago to test the Java version ( a most helpful developer in the Propeller world wrote in some early Propeller books- forgive me for forgetting again... just not good with names like that) , that let's you plot live data and make widgets to show/control pin state. That was an interesting direction that I pursued myself for a while because I wanted that interface for my daily driver, which rarely is Windows or Linux, and never Mac. It is currently Haiku. but I know I am an odd one, like lots of people drawn to Propeller. Even if I toted windows machines every day, I have a half dozen machines in rotation right now, having the right software loaded on the right machine at the right time becomes a headache, no matter what you're running for either OS or PLC control software.
Option 3) Use the MMEdit IDE (Win or Linux):
do you currently do this with Maxamite devices? would hardware need to emulate the Maxamite to work with this scenario with MMEdit?
Option 4) Use any editor and download with AUTOSAVE command.
in the *BASIC, or similar potentailly scripted languages, do you write the complete logic/flow ad-hoc on each device? or, is there some "runtime" function that ensures nothing gets in a bad state? or do you each build up your own bespoke library over time for the factory or equipment you tend to use?
@Mickster as you're one in the trenches, I wonder what you think about any of the points in this blog post. If you chuckle, that is fine, and a sign that there is a nugget of truth in some of the issues brought up here: https://www.breen-machine.com/breen-machine-presents-the-perfect-plc/
not just editor, but a live HMI into the system, for complete state examination and control. Live debugging, step, step, step and watch the hardware respond. See the state of all the I/O live, or halt/step to twiddle the state of a pin or DAC or PWM or servo outputs.
Yup. What happens when you need to know if a sensor is good/bad but it's out of sight of your HMI? Recruit help to activate the sensor while you watch the screen?
This is one of the reasons for my mobile HMI (Bluetooth)
No schematics in the cabinet or they are in tatters?
Machine setup information
Setting-up a new servo-drive. End-user either doesn't have a scope or he doesn't know how to drive it We handle all the PID so that all that needs to happen on the new drive is set to (dumb) torque mode with the appropriate current scaling and we calibrate from the tablet
We have had the computing power for many years now for a control system to include full diagnostics, datasheets, how-to videos, Skype/TeamViewer integration but I have seen nothing close to what I do with simple, free tools.
Any one of this community, if we had a failed 24v input, we're opening-up that fancy plastic box and we are replacing that $0.50 optocoupler. Why are people waiting for an entire replacement 16-input module?
Because the industry giants wanna keep them on the hook. They don't care that you lost a contract because you failed to deliver.
Brainwashed engineer: "Ah but you don't understand, this is industrial"
Optocoupler inputs, mosfet outputs; they need to be accessible and there needs to be a care package inside the panel
We write 100% of our code with an emphasis on safety; multiple watchdogs, following error traps that cannot be made unreasonable, any signal that triggers motion must have both a N/C and a N/O contact, etc.
@refaQtor said:
@Mickster as you're one in the trenches, I wonder what you think about any of the points in this blog post. If you chuckle, that is fine, and a sign that there is a nugget of truth in some of the issues brought up here: https://www.breen-machine.com/breen-machine-presents-the-perfect-plc/
It's obvious that he's spent at least 5 mins on PLCs.net
It's really painful when you realize that soooo many of these problems can be eliminated with Propeller technology. I ruffled some feathers when I was pushing the Prop there, some time ago
You get stuff like "I need 2Khz PWM from my AB [something-or-other]"
"Oh no problem, you need this $1,200 add-on device but you might need help to get it working"
@Mickster
Any one of this community, if we had a failed 24v input, we're opening-up that fancy plastic box and we are replacing that $0.50 optocoupler.
All interesting bits. Thank you! Just last night, as I was laying out the flexible I/O suitable the flexibility of the P2 SmartPins, I was toying with an expansion board for the P2 2x6 expansion ports that combined this TI RS232/422/485 port part that could alternately, configured through software, use the same 8 I/O to use all of their normal SmartPin features through the usual optocoupler/etc protection routed around the TI Serial Bus. That'll take a few iterations to get as correct as possible, barring anything, obviously, that is mutually exclusive electrically.... anyway, to have that relatively low cost port electronic interface be swappable for just the instance you suggest. not $0.50 alone, but less of the technicians time to deal with, as they'd come in a price point that meant they could keep a couple spares right with the unit.
It's really painful when you realize that soooo many of these problems can be eliminated with Propeller technology. I ruffled some feathers when I was pushing the Prop there, some time ago
yeah... when you march to the beat of a different drummer, so to speak, there really is no explaining that there is a better way. You just have to go out and show them, as you've done. Very nice work on your product. Keep up the great work.
Scenario: Production line down. Hourly employees stood around waiting until someone who understands C or Forth comes along? Not realistic.
I'm curious about these situations; the frequencies, causes and solutions.
I can imagine a few scenarios, like...
hardware failure - controller needs replacing and the same firmware installing (I suppose usually when "the guy" is on holiday, and when he's not given his assistant the tools to properly take over)
parameter variation - one example would be that the item on the line changed somehow, and so the controller firmware needs adjusting appropriately (in your experience, is that stuff usually scheduled to when "the guy" is on-site?)
No doubt you have many more examples?? My two don't seem like they should be issues at all, not withstanding the high-value sales income to be had from a service contract when things fail)
How about this:
Firmware change to product messes up the test procedure in the Mexican production plant.
The UUT-facing part of the tester relies on P1 for some vital functions.
Poor Test equipment engineer in Ohio works with plant engineering to find the problem on a holiday. Modified program for P1 required.
Modified P1 program sent to Mexico, Plant engineering can obtain Propeller tool and run it, load the new SPIN into P1 without admin rights.. Problem solved. (Happens a few times a year. Always just before a holiday or weekend. Yes, our software team is evil..)
OR
catastrophic failure of UUT damages tester, including the UUT facing FLIP (UUT involves line voltage, and somehow got built on a board with a copper short from HVrail to 3V3... Really, you can only add so much protection...)
FLIP is easily obtained for replacement. P1 program sent to Taiwan, Plant engineering can obtain Propeller tool and run it, load the new SPIN into P1 without admin rights.. Problem solved.
I once started on a ladder logic interpreter for P1.. It would be easier for P2. If the programming software is then available freely (See the Automation Direct PLCs..) this could result in wider use of P1 and/or P2 in industry. While the languages available for Propeller are widely understood, In the US at least, a PLC won't be seriously considered unless it supports animated Ladder Logic, with which EVERY plant Engineer and Electrician is comfortable.
It would be SWEET if someone could make a P1,2 compiler for Codesys.. I lack the skills and time... and it would be a monumental task to implement with the very comprehensive live animation in both ladder and STL..
The problem with a P2-me-too (same old, same old) development is that you'll be going right up against Arduino PLC and also their Portenta Machine Controller (zero galvanic isolation, BTW )
PLC won't be seriously considered unless it supports animated Ladder Logic
Good point...forgot about the animated bit.
Makes more sense to create a Parallax Propeller PLC mobile app that would be a free simulator (exposure) that could create control programs for the P2, transferred via Bluetooth/WiFi.
@Mickster said:
The problem with a P2-me-too (same old, same old) development
I've never been for same old, same old. for just the reason you point out. Unless you can show off the unique features of P2, I have no interest in making a control system that is burdened by all the same issues as the rest of the market.
BTW, I do have an Aduino OPTA.... unimpressed in their software and limited serial interface expandability options compared to other "economy" options like CLICK PLC, for example. Their own PLC IDE has worked a total of ONE TIME, and I've burnt too many hours to get them to play well togther. On the other hand. the OpenPLC software has connected EVERY TIME, painlessly.
BTW, I do have an Aduino OPTA.... unimpressed in their software and limited serial interface expandability options compared to other "economy" options like CLICK PLC, for example. Their own PLC IDE has worked a total of ONE TIME, and I've burnt too many hours to get them to play well togther. On the other hand. the OpenPLC software has connected EVERY TIME, painlessly.
Interesting
The P2 could be killer
I was reading, recently, about the limitations of separate PLC and Motion Controller. The P2 can handle both with ease.
PLC won't be seriously considered unless it supports animated Ladder Logic
Good point...forgot about the animated bit.
Makes more sense to create a Parallax Propeller PLC mobile app that would be a free simulator (exposure) that could create control programs for the P2, transferred via Bluetooth/WiFi.
Mobile app approach makes a lot of sense. Most modern PLC dev software seems to compile the language and then load the PLC with whatever native assembly the processor in question uses, and then is unable to retrieve the source from the PLC unless it was specifically saved to the PLC as well. (Older ones seemed to tokenize the logic and the PLC interpreted that...)
I need to check for sure, but I seem to remember that more than one of the big PLC makers, maybe even Codesys, compile Ladder into STL before then compiling the target assembly.. it makes me wonder how hard it would be to convert some subset of Ladder, or STL into SPIN. With SPIN the code density goes way up, and interpreted SPIN still will run circles around most PLCs..
@"R Baggett" said:
I need to check for sure, but I seem to remember that more than one of the big PLC makers, maybe even Codesys, compile Ladder into STL before then compiling the target assembly.. it makes me wonder how hard it would be to convert some subset of Ladder, or STL into SPIN. With SPIN the code density goes way up, and interpreted SPIN still will run circles around most PLCs..
It looks like the syntax for STL isn't that different from BASIC or Pascal. So in principle it seems like it wouldn't be too hard to add a front end for it to flexspin, which would allow output to either PASM or bytecodes. But I know nothing about PLCs, so I may be missing some crucial piece. I guess the hard part would probably be the run time library.
@"R Baggett" said:
I need to check for sure, but I seem to remember that more than one of the big PLC makers, maybe even Codesys, compile Ladder into STL before then compiling the target assembly.. it makes me wonder how hard it would be to convert some subset of Ladder, or STL into SPIN. With SPIN the code density goes way up, and interpreted SPIN still will run circles around most PLCs..
It looks like the syntax for STL isn't that different from BASIC or Pascal. So in principle it seems like it wouldn't be too hard to add a front end for it to flexspin, which would allow output to either PASM or bytecodes. But I know nothing about PLCs, so I may be missing some crucial piece. I guess the hard part would probably be the run time library.
Yes, it is quite similar to structured BASIC / Pascal (and Modula-2 / Oberon descendants).
Nice would be some form of SourceCodeLine:BinaryAdr mapping debug file, that would support single step debug.
A list of data types is here, but 100% coverage is nice but not essential. Items like TIME / DATE etc are (implementer specific).
Elementary Data Type
Bit Strings – groups of on/off values
BOOL - 1 bit (0,1)
BYTE – 8 bit (1 byte)
WORD – 16 bit (2 byte)
DWORD – 32 bit (4 byte)
LWORD – 64 bit (8 byte)
INTEGER – whole numbers (Considering byte size 8 bits)
SINT – signed short integer (1 byte)
INT – signed integer (2 byte)
DINT – signed double integer (4 byte)
LINT – signed long integer (8 byte)
USINT – Unsigned short integer (1 byte)
UINT – Unsigned integer (2 byte)
UDINT – Unsigned double integer (4 byte)
ULINT – Unsigned long integer (8 byte)
REAL – floating point IEC 60559 (same as IEEE 754-2008)
REAL – (4 byte)
LREAL – (8 byte)
Character / Character string
CHAR – Single-byte character (1 byte, limited to characters 0 to 255 of ISO/IEC 10646)
WCHAR – Double-byte character (2 byte, limited to characters 0 to 65535 of ISO/IEC 10646)
STRING – Variable-length single-byte character string. Literals specified with single quote, 'This is a STRING Literal'
WSTRING – Variable-length double-byte character string. Literals specified with a double quote, "This is a WSTRING Literal"
Duration literals
Unit Description
d Day
h Hour
m Minute
s Second
ms Millisecond
us Microsecond
ns Nanosecond
Duration [4]
TIME – (implementer specific). Literals in the form of T#5m90s15ms
LTIME – (8 byte). Literals extend to nanoseconds in the form of T#5m90s15ms542us15ns
Date
DATE – calendar date (implementer specific)
LDATE – calendar date (8 byte, nanoseconds since 1970-01-01, restricted to multiple of one day)
Time of day
TIME_OF_DAY / TOD – clock time (implementer specific)
LTIME_OF_DAY / LTOD – clock time (8 byte)
Date and time of Day
DATE_AND_TIME / DT – time and date (implementer specific)
LDATE_AND_TIME / LDT – time and date (8 byte, nanoseconds since 1970-01-01)
Comments
Kind of wondering if should implement this in Micropython as the infrastructure is already there...
Would be concerned about it being too slow though... Unless actually compiled...
@Mickster , I totally agree. I'm not keen on Ladder myself, especially as math and string handling has encroached on the space. I only explore it as a simple option to put in place all the other parts of the system.
what are your thoughts of an ANSI interface that you could interface with just a terminal, perhaps on a laptop, and not toting extra VGA/keyboard?
I would like both, to be able to leave vga display and keyboard attached at some workstations, while others may be headless.
@Rayman , yes, I like it.
NO ! NO ! NO !...
it is the ever shifting sands of the Python environment and libs that are the BANE OF MY EXISTENCE!
I want the very least between my system code and the hardware, and not have that infrastructure with the potential to screw up the critical clock-sensitive operations
The ansi VGA driver might be better at lower resolution (1024x768) but with 16x8 characters instead of 32x16.
This gives more text and might not have to implement scrolling for simple designs...
Also thinking that Micropython has a text editor already.
If a ".ld" file is going to be the input to whatever this is, can already edit this on P2...
This already works with both VGA and terminal...
Perhaps graphical editing can come later and start with just graphical inspection...
well, the more the merrier, I guess.
plenty of room for everyone. and, well, the code editor doesn't need precise real-time operation at all.
so, it might be a quick path to try thinggs out.
You want C then
There will be various kludge methods, that stuff binary values for PIO, as already done in C.
Or, you can use an external PIO assembler and import a HEX or BIN array.
Has anyone done a PIO assembler / simulator ?
I can see your point, but a key advantage of Oberon + Pi PICO is an enthusiastic employee can easily learn at home, they do not need an expensive custom PLC.
There are always limits to the quick and dirty pathway of _ 'grabbing a USB keyboard and a VGA monitor, editing and instantly testing/running code'_ as you really do need to save and document the code at some point.
PC hosts that can edit code, search the web, access AI, and read PDFs and create documents as well as compile download and run, cover the bases nicely.
What they need is a good way to single step the target for debug.
The Venerable TurboPascal solved tight integration of Edit+Compile+Debug.
Oberon looked interesting to me, too. Support for Pi Pico PIO is the first issue I checked for.
I found these
https://github.com/adafruit/Adafruit_CircuitPython_PIOASM?tab=readme-ov-file
that seems to assembler to an array, but none of their examples include copy of actual output, so it is not easy to grock the limits.
and this
https://github.com/NathanY3G/rp2040-pio-emulator/blob/main/docs/Quick Start Guide.md
that seems to allow you to assemble using Adafruit_CircuitPython_PIOASM, then Emulate looping with a defined exit condition, giving your own custom format printf style reports.
Not very graphical, but good to archive and version track.
and this is a bit more graphical, using in.csv and out.csv files and readable in flow csv viewer
https://github.com/sumio-morioka/rpipico_simple_PIO_emulator?tab=readme-ov-file
and a picture of what flow csv can give
https://github.com/sumio-morioka/rpipico_simple_PIO_emulator/blob/main/waveform_sample2.png
I also find this
https://oberon-lang.github.io/2021/07/16/comparing-oberon+-with-oberon-2-and-07.html
and this variant mentions STM32 and MSP430 binary targets
https://github.com/AntKrotov/oberon-07-compiler
for those looking for self-hosting, there may be this compact pathway - the single pass M-Code compiler is quite small
I find M-Codes here
https://github.com/afborchert/mcode-decoder/blob/master/src/mcd_mnem.c
Text says 1,2 or 3 bytes but the decode.MOD file, shows decode for some rare 4 and 5 byte opcodes (ForJump and LID LoadImmediateDouble? )
and a scanned PDF is here
https://bitsavers.org/pdf/eth/lilith/Lilith_hardware_manual.pdf
Snip tool does OCR on a section
5.2.3 ALU Functions The ALU is the main theatre for operations concerned with the execution of the Lilith M-code instructions. To illustrate how the ALU would be involved in a sequence of M-code operations, we will examine the execution of the hypothetical Modula 2 statement: c := b + ap where "b" is declared a local variable of type INTEGER, "c" is a global variable of the same type, and "ap" is a global variable of type POINTER TO INTEGER. The sequence of M-codes emitted by the compiler for this statement would be: LL4 (* load the fourth local variable which is b *) LG3 (* load the third global variable which is ap *) LSWØ (* load word addressed by top of stack which is pointer value from ap *) ADD (* add the two operands *) SG5 (* store top of stack into fifth global variable which is c *)Not sure how similar all that is, to the existing P2 Spin Byte code interpreter ?
Sure:
Option 1) Connect KB, monitor, mouse directly
Option 2) Connect laptop/PC to USB and use something like Teraterm
This is what you get (color code can be switched on/off):
Option 3) Use the MMEdit IDE (Win or Linux):
Option 4) Use any editor and download with AUTOSAVE command.
@refaQtor
@jmg
PIO assembler (if you have a Pico)
PIO Assembler
Bit of an oxymoron in my world
Sure. We have a filing system and WiFi that does file transfers
This is why an industrial Android tablet serves as my HMI. Inexpensive, ubiquitous, connectivity, memory, GPU, etc.
Good point and not just single-stepping for code. A good program sequence is one where jumping to any location (sequence step) is possible. When a work-cell jams-up, we want to be able to resume without scrapping the valuable work-piece. Having to retract robots and reset every piece of process machinery is a major PITA.
QuickBASIC 4.5 IDE; suspend, edit, continue. What a time-saver
Glad that someone notices this. The way QB worked was just perfect, editing the code while it was paused, running testcode in between in this little console window..., F1 would give you detailed explanations for each command you point your cursor at.... Visual Basic does have that to some extend as far as i know but other languages lack that ability. Even in python, although you can use the console to call up routines and inspect variables, it's nowhere as fluid and convenient as QB was.
The problem: Live machine and some things couldn't be suspended
The solution: Hijack and reprogram the PC's clock from 55ms to (I forget) a couple of ms(?) and compensate to preserve the time keeping.
Share memory (variables) with QB. Run the critical code in the ISR. Who says DOS doesn't do realtime?
not just editor, but a live HMI into the system, for complete state examination and control. Live debugging, step, step, step and watch the hardware respond. See the state of all the I/O live, or halt/step to twiddle the state of a pin or DAC or PWM or servo outputs.
ALL OF THE ABOVE, though contstrained to ANSI text mode interface.
getting the live view/interaction can happen through some protocol and be displayed/controlled through a rich desktop interface... well, that is how all the proprietary systems work where you need to have loaded some compatible (maybe licensed) application on the version of OS that you have on your machine, etc. kinda all the stuff we're trying to get away from .
there is a nifty sort of HMI builder, even for the Propeller (that I keep forgetting the name) I used a year ago to test the Java version ( a most helpful developer in the Propeller world wrote in some early Propeller books- forgive me for forgetting again... just not good with names like that) , that let's you plot live data and make widgets to show/control pin state. That was an interesting direction that I pursued myself for a while because I wanted that interface for my daily driver, which rarely is Windows or Linux, and never Mac. It is currently Haiku. but I know I am an odd one, like lots of people drawn to Propeller. Even if I toted windows machines every day, I have a half dozen machines in rotation right now, having the right software loaded on the right machine at the right time becomes a headache, no matter what you're running for either OS or PLC control software.
do you currently do this with Maxamite devices? would hardware need to emulate the Maxamite to work with this scenario with MMEdit?
in the *BASIC, or similar potentailly scripted languages, do you write the complete logic/flow ad-hoc on each device? or, is there some "runtime" function that ensures nothing gets in a bad state? or do you each build up your own bespoke library over time for the factory or equipment you tend to use?
@Mickster as you're one in the trenches, I wonder what you think about any of the points in this blog post. If you chuckle, that is fine, and a sign that there is a nugget of truth in some of the issues brought up here: https://www.breen-machine.com/breen-machine-presents-the-perfect-plc/
Yup. What happens when you need to know if a sensor is good/bad but it's out of sight of your HMI? Recruit help to activate the sensor while you watch the screen?
This is one of the reasons for my mobile HMI (Bluetooth)
No schematics in the cabinet or they are in tatters?
Machine setup information
Setting-up a new servo-drive. End-user either doesn't have a scope or he doesn't know how to drive it
We handle all the PID so that all that needs to happen on the new drive is set to (dumb) torque mode with the appropriate current scaling and we calibrate from the tablet
We have had the computing power for many years now for a control system to include full diagnostics, datasheets, how-to videos, Skype/TeamViewer integration but I have seen nothing close to what I do with simple, free tools.
Any one of this community, if we had a failed 24v input, we're opening-up that fancy plastic box and we are replacing that $0.50 optocoupler. Why are people waiting for an entire replacement 16-input module?
Because the industry giants wanna keep them on the hook. They don't care that you lost a contract because you failed to deliver.
Brainwashed engineer: "Ah but you don't understand, this is industrial"
Optocoupler inputs, mosfet outputs; they need to be accessible and there needs to be a care package inside the panel
We write 100% of our code with an emphasis on safety; multiple watchdogs, following error traps that cannot be made unreasonable, any signal that triggers motion must have both a N/C and a N/O contact, etc.
It's really painful when you realize that soooo many of these problems can be eliminated with Propeller technology. I ruffled some feathers when I was pushing the Prop there, some time ago
You get stuff like "I need 2Khz PWM from my AB [something-or-other]"
"Oh no problem, you need this $1,200 add-on device but you might need help to get it working"
Fridiculous
All interesting bits. Thank you! Just last night, as I was laying out the flexible I/O suitable the flexibility of the P2 SmartPins, I was toying with an expansion board for the P2 2x6 expansion ports that combined this TI RS232/422/485 port part that could alternately, configured through software, use the same 8 I/O to use all of their normal SmartPin features through the usual optocoupler/etc protection routed around the TI Serial Bus. That'll take a few iterations to get as correct as possible, barring anything, obviously, that is mutually exclusive electrically.... anyway, to have that relatively low cost port electronic interface be swappable for just the instance you suggest. not $0.50 alone, but less of the technicians time to deal with, as they'd come in a price point that meant they could keep a couple spares right with the unit.
yeah... when you march to the beat of a different drummer, so to speak, there really is no explaining that there is a better way. You just have to go out and show them, as you've done. Very nice work on your product. Keep up the great work.
How about this:
Firmware change to product messes up the test procedure in the Mexican production plant.
The UUT-facing part of the tester relies on P1 for some vital functions.
Poor Test equipment engineer in Ohio works with plant engineering to find the problem on a holiday. Modified program for P1 required.
Modified P1 program sent to Mexico, Plant engineering can obtain Propeller tool and run it, load the new SPIN into P1 without admin rights.. Problem solved. (Happens a few times a year. Always just before a holiday or weekend. Yes, our software team is evil..)
OR
catastrophic failure of UUT damages tester, including the UUT facing FLIP (UUT involves line voltage, and somehow got built on a board with a copper short from HVrail to 3V3... Really, you can only add so much protection...)
FLIP is easily obtained for replacement. P1 program sent to Taiwan, Plant engineering can obtain Propeller tool and run it, load the new SPIN into P1 without admin rights.. Problem solved.
I once started on a ladder logic interpreter for P1.. It would be easier for P2. If the programming software is then available freely (See the Automation Direct PLCs..) this could result in wider use of P1 and/or P2 in industry. While the languages available for Propeller are widely understood, In the US at least, a PLC won't be seriously considered unless it supports animated Ladder Logic, with which EVERY plant Engineer and Electrician is comfortable.
It would be SWEET if someone could make a P1,2 compiler for Codesys.. I lack the skills and time... and it would be a monumental task to implement with the very comprehensive live animation in both ladder and STL..
i found this useful for context:
from: breen-machine.com
The problem with a P2-me-too (same old, same old) development is that you'll be going right up against Arduino PLC and also their Portenta Machine Controller (zero galvanic isolation, BTW
)
@R Baggett
Good point...forgot about the animated bit.
Makes more sense to create a Parallax Propeller PLC mobile app that would be a free simulator (exposure) that could create control programs for the P2, transferred via Bluetooth/WiFi.
I've never been for same old, same old. for just the reason you point out. Unless you can show off the unique features of P2, I have no interest in making a control system that is burdened by all the same issues as the rest of the market.
BTW, I do have an Aduino OPTA.... unimpressed in their software and limited serial interface expandability options compared to other "economy" options like CLICK PLC, for example. Their own PLC IDE has worked a total of ONE TIME, and I've burnt too many hours to get them to play well togther. On the other hand. the OpenPLC software has connected EVERY TIME, painlessly.
Interesting
The P2 could be killer
I was reading, recently, about the limitations of separate PLC and Motion Controller. The P2 can handle both with ease.
Mobile app approach makes a lot of sense. Most modern PLC dev software seems to compile the language and then load the PLC with whatever native assembly the processor in question uses, and then is unable to retrieve the source from the PLC unless it was specifically saved to the PLC as well. (Older ones seemed to tokenize the logic and the PLC interpreted that...)
I need to check for sure, but I seem to remember that more than one of the big PLC makers, maybe even Codesys, compile Ladder into STL before then compiling the target assembly.. it makes me wonder how hard it would be to convert some subset of Ladder, or STL into SPIN. With SPIN the code density goes way up, and interpreted SPIN still will run circles around most PLCs..
It looks like the syntax for STL isn't that different from BASIC or Pascal. So in principle it seems like it wouldn't be too hard to add a front end for it to flexspin, which would allow output to either PASM or bytecodes. But I know nothing about PLCs, so I may be missing some crucial piece. I guess the hard part would probably be the run time library.
Yes, it is quite similar to structured BASIC / Pascal (and Modula-2 / Oberon descendants).
Nice would be some form of SourceCodeLine:BinaryAdr mapping debug file, that would support single step debug.
A list of data types is here, but 100% coverage is nice but not essential. Items like TIME / DATE etc are (implementer specific).
https://en.wikipedia.org/wiki/IEC_61131-3