Let's say I cat a C source file into fileName.c. Now my gcc knows to compile that as a C source not a C++ source or whatever.
If we used metadata instead of file extensions presumably I would have to some how edit that metadata to make sure it's of the same type as the original file.
No thanks.
Version info and all that update log metadata should be in git.
"cat -meta" is hard work and no doubt produces the wrong result. The new file now has all the same metadata as the original. and it presumes that even want the file to remain a C source. Maybe I want it to be plain text or whatever?
You don't have to worry much. Linux is never, ever going to go there. And I don't mind.
However, the "hard work" argument is the same one people use to avoid all kinds of data and meta data options that do them a lot of good, once they actually invest in that work. And the resolution is always the same. Where it's actually formalized, consensus is forced, and a lot of higher level things get easier / more efficient and or sometimes merely possible in return for a bit more work here and there.
Git is a perfect case in point. And I see this near constantly in the context of mechanical CAD. People will do crazy things to keep files organized, meta data intact, etc... and those things are often more consistent work and deny them options they would have otherwise. But it's "hard work" to actually manage data.
Of course, once they do, they never, ever go back. It's easy then.
You are doing that work anyway. It's just at a different point and place in the process. However, what you aren't doing is actually getting any real benefit from the work.
Okay, I see now that RISC OS was invented in the 80's. I suppose there was a lot more variation in operating systems back then. I still don't understand why MS-DOS chose backslash instead of forward slash like Unix used at the time.
Specifically IBM partitioned datasets and VAX/VMS would likely be the influences for RISCOS, both using '.' for
directory separator I think.
The ICL/Singer/Frieden System Ten which was released in 1969 used "." as the directory-file separator. Drives were numeric and separated by ":".
So we had 0:poolname.filename where poolname and filename were 6 alphanumerics each, with some special characters allowed too, but no spaces except at the end.
BTW back in the day, Disc Drives were spelt with a "c" not a "k". There were no problems with cases either because it was 6-bit ASCII uppercase only
And printers had to be lifted in by cranes and cost >$20K
@Heater:
The argument of vs C++, etc is one that is easily handled. In most systems that have the metadata for filetype stored seperate from the name, most source is just TEXT, and then is the one and only time that file name extensions are used. Many programming language standards specify a file name extension, so it makes since.
Though even the example you gave had to include the filetype Metadata (the .c in the filename).
Unix, Linux, etc all have one bad idea. They use file name extensions for most data files, though not for executables. You can have a binary executable named MyProg.text and it would be valid in *nix, so we are in a hard place with modern systems as well.
Not to mention file access controlled by metadata that just provides Owner, Group, other type stuff, with three bits of info for the access permissions at each level. That seems a poor way to manage things to me.
How often do you have to use chown to get something working? Linux is no better off than any other.
_________________________________
With all this OT stuff I am going to have to start putting the firmware src in the first post.
I have put the two files that are complete in the first post of the thread, as attachments. If any error is found in these, please let me know. If you have any suggestions for improvements, also please let me know.
I find lots of problems with your servo/heater driver. How do you start it? What happens if you want to change pins?
Attached you'll find a re-write that behaves like a traditional object. You can pass the pins to it. It has start() and stop() methods. With this design you can have more than one copy of this object running if you need (dual extruder?).
Be careful not to let your formatting get away from you as it can cause unforced errors.
I find lots of problems with your servo/heater driver. How do you start it? What happens if you want to change pins?
Attached you'll find a re-write that behaves like a traditional object. You can pass the pins to it. It has start() and stop() methods. With this design you can have more than one copy of this object running if you need (dual extruder?).
Be careful not to let your formatting get away from you as it can cause unforced errors.
I hope you find this helpful.
I do thank you. I will look at your code for sure.
To stop you set the servo to center.
To do an all stop switch to a non attached set (That object is not yet shown, though I have thought about multiple extruders with out taking up pins)
I find lots of problems with your servo/heater driver. How do you start it? What happens if you want to change pins?
Attached you'll find a re-write that behaves like a traditional object. You can pass the pins to it. It has start() and stop() methods. With this design you can have more than one copy of this object running if you need (dual extruder?).
Be careful not to let your formatting get away from you as it can cause unforced errors.
I hope you find this helpful.
I do thank you. I want to keep it general purpose, and I did to much hard coding for sure. The idea was set heat to 0 to stop the heating element (I am using ULN2803's for current syncs, that are controlled from the Propeller), and to stop the servo just set the position to centered (0 as the speed parameter).
Though multiple copies could come in useful for multiple extruders so that one can be heated while another is still printing, and pre-feed the filament. That would make less waiting when switching heads. I was just running them through buffers, and using the chip select on the buffers to select which extruder assembly is enabled (going for up to 8 possible extruders from one Prop, though my HW is only set up for up to 4).
I do thank you for your input, that is actually very helpful. I have not had any time today to work on this yet, though I like your source file.
Though some of the control code goes in a different Object (the control object I have not yet posted, as it will not be complete until every thing else is).
@JonnyMac:
I added your name in the author line of the one you provided.
That is an interesting means of range checking, I need to brush up on my SPIN, I had been using IF statements where I need range checking.
Here is a quick update of my code with your suggestions.
'This provides PWM based control of one servo, and PWM control of one heating element.
'This code is based losely on the parallax Servo Example code.
CON
VAR
LONG HeatTime,IncTmp,Cycle,SrvTime,t
LONG ServoPin, HeatingPin
PUB Init(S,H)
ServoPin := S
HeatingPin := H
COGNEW DoIt
AllStop
SrvMov(0)
HeatLvl(0)
PUB SrvMov(S) 'S must be in the range of -200 to 200.
'S is the speed for a continous rotation servo,
' or the angle for a standard servo.
s := -200 #> S <# 200
IncTmp := clkfreq/1000000
Cycle := IncTmp * 20000
SrvTime := IncTmp * (1500+S)
PUB HeatLvl(H) 'H must be between 0 and 100. 100 is max heat, and equal to 50%
'duty cucle.
H := 0 #> H <# 100
HeatTime := clkfreq/(100*H)
PRI DoIt 'This procedure runs by itself on a COG.
'Just prerforms the output repeatedly, for both the Heating element, and the servo.
ctra[30..26] := %00100
ctra[8..0] := ServoPin
ctrb[30..26] := %00100
ctrb[8..0] := HeatingPin
t := cnt
repeat
phsa := -SrvTime
phsb := -HeatTime
t += Cycle
waitcnt(t)
DAT
{{
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ TERMS OF USE: MIT License │
├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation │
│files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, │
│modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software│
│is furnished to do so, subject to the following conditions: │
│ │
│The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.│
│ │
│THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE │
│WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR │
│COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, │
│ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
}}
Also note that the counter setup now uses the cog it that the output code is running in. That is an error we both overlooked.
And the maximum for the heating element is supposed to be 50% duty cycle (as given in the comment above).
Again if anyone notices any errors, or has suggestions for improvement, please let me know.
To do an all stop switch to a non attached set (That object is not yet shown, though I have thought about multiple extruders with out taking up pins)
That's not what I meant about stop. When you have an object that consumes a cog, good design practice dictates that you have a method called stop() to unload that cog if necessary. You'll see that the start() method in my version allows you to pass the pin #s (you should keep all of those in your top object; if the design changes you don't have to scramble through multiple files to find pin connections).
I implemented your features, just in a cleaner fashion (limit checks, professional formatting, etc.). To move the servo to center you call set_pos(0). In fact, the start() method of the object calls set_pos() and set_heat() to ensure the control variables are properly setup before launching the pwm cog.
Also note that the counter setup now uses the cog it that the output code is running in. That is an error we both overlooked.
I didn't. If you look at my rewrite you'll see that the counters and pins are properly setup in the dual_pwm() method that is launched into its own cog. I've been doing servos and pwm motor control for professionals for a long time. I'm pretty good at it.
And the maximum for the heating element is supposed to be 50% duty cycle (as given in the comment above).
Use that as a setting in your top object and control it from there.
I added your name in the author line of the one you provided.
Please do not put my name on anything. It is my professional name (SAG/AFTRA) and I take it very seriously. I simply re-wrote your object the way you will when you have more experience with Spin. Please remove my name.
That's not what I meant about stop. When you have an object that consumes a cog, good design practice dictates that you have a method called stop() to unload that cog if necessary. You'll see that the start() method in my version allows you to pass the pin #s (you should keep all of those in your top object; if the design changes you don't have to scramble through multiple files to find pin connections).
I implemented your features, just in a cleaner fashion (limit checks, professional formatting, etc.). To move the servo to center you call set_pos(0). In fact, the start() method of the object calls set_pos() and set_heat() to ensure the control variables are properly setup before launching the pwm cog.
And I do thank you much. I implemented most of your suggestions (as shown above). I am passing the pin assignments in, and am setting the initial speed (not relying on the compiler to zero the variables).
The 50% duty cycle MAX for the heating element is based on my experience with the heating element and 12 volt driver combination I am using.
I also moved the COGNEW command to the object (it was in the command and control object). Thank you again for the method of range checking it is more efficient.
There is no stop as the cog continues running as long as the firmware is in use, so nothing to stop (it should not stop unless power is removed, or a reset applied).
In the rewrite above did I get everything that you noticed? If there is anything else I am open to suggestion.
Not much today. Though I have made some good progress on the main control object, and the command interpreter (both are fairly simple).
I have to get started on the thermistor inputs (using sigma delta ADC), to monitor temperature. Then just add in the standard single cog serial, and One Pin TV text, then it should be complete, just a matter of working through to get everything working correctly together.
The native commands have changed a little from the first posting of them. The native commands are now:
'Command processor.
'This uses a simple set of byte commands.
{The Commands are one byte folowed by one or two bytes of data.
The current commands are:
00nnnn = Move X, forward.
01nnnn = Move Y forward.
02nnnn = Move Z forward.
04nnnn = Move X reverse.
05nnnn = Move Y reverse.
06nnnn = Move Z reverse.
08nn = Set Current X Speed.
09nn = Set Current Y Speed.
0Ann = Set Current Z Speed.
0Bnn = Set Current Extrusion Speed.
0Fnn = Set Current Extruder Temperature.
10 = Zero X.
11 = Zero Y.
12 = Zero Z
14 = Set current X position as Zero.
15 = Set current Y position as Zero.
16 = Set current Z position as Zero.
18nnnn = Set current X position as nnnn.
19nnnn = Set current Y position as nnnn.
1Annnn = Set current Z position to nnnn.
1Cnnnn = Set Maximum X position to nnnn.
1Dnnnn = Set Maximum Y position to nnnn.
1Ennnn = Set Maximum Z position to nnnn.
20nn = Select Extruder.
21nn = Set Current Feed Rate.
22nn = Set Heat for current Extruder.
30 = Set Simulation Mode (does all the X/Y/Z movements, with the extruder turned off).
31 = UnSet Simulation Mode (back to regular print mode).
80nnnn = Set repeat counter.
81nnnn = Decrease repeat counter by one and go back up to 65535 bytes if repeat counter not zero.
84nn = Set small repeat counter.
85nn = Decrease Small Repeat Counter and go back up to 255 bytes if small repeat counter is not zero.
F0 = All Stop.
FF = Print Done (Turn off extruder(s), zero X and Y, move Z to maximum)..
}
as extracted from the comments that I am attempting to keep up to date with the code.
This is a result of attempting to reduce memory usage for buffering commands. G-Code is huge compared to these commands to do the same thing.
The repeat commands ($80 and $81) are to save even more space where two or more layers are identical.
I think I am nearly done. I will be doing a test run later today (likely this evening), and if all works alright I will be uploading a complete version 0.0.1 of this control software.
It will be a 0.0.1 do to not yet having a G-Code processor (only uses the native command language), and no serial communications.
The next step will be to add the G-Code interpreter, and then serial communication in a way that is compatible with standard 3D printer software. The first version of the G-Code interpreter will have to convert the entire sequence into native command code, it will be later extended to allow for better dynamic upload of stuff (as done in most 3D printers that usually have less than 4KB of data ram to work with), and allow for G-Code that converts to native Code larger than 16KB (the space allocated for the native code buffer), though I expect that to be rare.
I am also going to have to figure out a way to allow for uploading either G-Code or native code to the Propeller. That will be interesting, especially with out breaking compatibility.
Comments
Let's say I cat a C source file into fileName.c. Now my gcc knows to compile that as a C source not a C++ source or whatever.
If we used metadata instead of file extensions presumably I would have to some how edit that metadata to make sure it's of the same type as the original file.
No thanks.
Version info and all that update log metadata should be in git.
"cat -meta=C" is even more hard work.
No thanks.
However, the "hard work" argument is the same one people use to avoid all kinds of data and meta data options that do them a lot of good, once they actually invest in that work. And the resolution is always the same. Where it's actually formalized, consensus is forced, and a lot of higher level things get easier / more efficient and or sometimes merely possible in return for a bit more work here and there.
Git is a perfect case in point. And I see this near constantly in the context of mechanical CAD. People will do crazy things to keep files organized, meta data intact, etc... and those things are often more consistent work and deny them options they would have otherwise. But it's "hard work" to actually manage data.
Of course, once they do, they never, ever go back. It's easy then.
You are doing that work anyway. It's just at a different point and place in the process. However, what you aren't doing is actually getting any real benefit from the work.
Specifically IBM partitioned datasets and VAX/VMS would likely be the influences for RISCOS, both using '.' for
directory separator I think.
So we had 0:poolname.filename where poolname and filename were 6 alphanumerics each, with some special characters allowed too, but no spaces except at the end.
BTW back in the day, Disc Drives were spelt with a "c" not a "k". There were no problems with cases either because it was 6-bit ASCII uppercase only
And printers had to be lifted in by cranes and cost >$20K
The argument of vs C++, etc is one that is easily handled. In most systems that have the metadata for filetype stored seperate from the name, most source is just TEXT, and then is the one and only time that file name extensions are used. Many programming language standards specify a file name extension, so it makes since.
Though even the example you gave had to include the filetype Metadata (the .c in the filename).
Unix, Linux, etc all have one bad idea. They use file name extensions for most data files, though not for executables. You can have a binary executable named MyProg.text and it would be valid in *nix, so we are in a hard place with modern systems as well.
Not to mention file access controlled by metadata that just provides Owner, Group, other type stuff, with three bits of info for the access permissions at each level. That seems a poor way to manage things to me.
How often do you have to use chown to get something working? Linux is no better off than any other.
_________________________________
With all this OT stuff I am going to have to start putting the firmware src in the first post.
Attached you'll find a re-write that behaves like a traditional object. You can pass the pins to it. It has start() and stop() methods. With this design you can have more than one copy of this object running if you need (dual extruder?).
Be careful not to let your formatting get away from you as it can cause unforced errors.
I hope you find this helpful.
To stop you set the servo to center.
To do an all stop switch to a non attached set (That object is not yet shown, though I have thought about multiple extruders with out taking up pins)
I do thank you. I want to keep it general purpose, and I did to much hard coding for sure. The idea was set heat to 0 to stop the heating element (I am using ULN2803's for current syncs, that are controlled from the Propeller), and to stop the servo just set the position to centered (0 as the speed parameter).
Though multiple copies could come in useful for multiple extruders so that one can be heated while another is still printing, and pre-feed the filament. That would make less waiting when switching heads. I was just running them through buffers, and using the chip select on the buffers to select which extruder assembly is enabled (going for up to 8 possible extruders from one Prop, though my HW is only set up for up to 4).
I do thank you for your input, that is actually very helpful. I have not had any time today to work on this yet, though I like your source file.
Though some of the control code goes in a different Object (the control object I have not yet posted, as it will not be complete until every thing else is).
I added your name in the author line of the one you provided.
That is an interesting means of range checking, I need to brush up on my SPIN, I had been using IF statements where I need range checking.
Here is a quick update of my code with your suggestions.
'This provides PWM based control of one servo, and PWM control of one heating element. 'This code is based losely on the parallax Servo Example code. CON VAR LONG HeatTime,IncTmp,Cycle,SrvTime,t LONG ServoPin, HeatingPin PUB Init(S,H) ServoPin := S HeatingPin := H COGNEW DoIt AllStop SrvMov(0) HeatLvl(0) PUB SrvMov(S) 'S must be in the range of -200 to 200. 'S is the speed for a continous rotation servo, ' or the angle for a standard servo. s := -200 #> S <# 200 IncTmp := clkfreq/1000000 Cycle := IncTmp * 20000 SrvTime := IncTmp * (1500+S) PUB HeatLvl(H) 'H must be between 0 and 100. 100 is max heat, and equal to 50% 'duty cucle. H := 0 #> H <# 100 HeatTime := clkfreq/(100*H) PRI DoIt 'This procedure runs by itself on a COG. 'Just prerforms the output repeatedly, for both the Heating element, and the servo. ctra[30..26] := %00100 ctra[8..0] := ServoPin ctrb[30..26] := %00100 ctrb[8..0] := HeatingPin t := cnt repeat phsa := -SrvTime phsb := -HeatTime t += Cycle waitcnt(t) DAT {{ ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ TERMS OF USE: MIT License │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation │ │files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, │ │modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software│ │is furnished to do so, subject to the following conditions: │ │ │ │The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.│ │ │ │THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE │ │WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR │ │COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, │ │ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ }}Also note that the counter setup now uses the cog it that the output code is running in. That is an error we both overlooked.And the maximum for the heating element is supposed to be 50% duty cycle (as given in the comment above).
Again if anyone notices any errors, or has suggestions for improvement, please let me know.
That's not what I meant about stop. When you have an object that consumes a cog, good design practice dictates that you have a method called stop() to unload that cog if necessary. You'll see that the start() method in my version allows you to pass the pin #s (you should keep all of those in your top object; if the design changes you don't have to scramble through multiple files to find pin connections).
I implemented your features, just in a cleaner fashion (limit checks, professional formatting, etc.). To move the servo to center you call set_pos(0). In fact, the start() method of the object calls set_pos() and set_heat() to ensure the control variables are properly setup before launching the pwm cog.
I didn't. If you look at my rewrite you'll see that the counters and pins are properly setup in the dual_pwm() method that is launched into its own cog. I've been doing servos and pwm motor control for professionals for a long time. I'm pretty good at it.
Use that as a setting in your top object and control it from there.
Please do not put my name on anything. It is my professional name (SAG/AFTRA) and I take it very seriously. I simply re-wrote your object the way you will when you have more experience with Spin. Please remove my name.
The 50% duty cycle MAX for the heating element is based on my experience with the heating element and 12 volt driver combination I am using.
I also moved the COGNEW command to the object (it was in the command and control object). Thank you again for the method of range checking it is more efficient.
There is no stop as the cog continues running as long as the firmware is in use, so nothing to stop (it should not stop unless power is removed, or a reset applied).
In the rewrite above did I get everything that you noticed? If there is anything else I am open to suggestion.
I have to get started on the thermistor inputs (using sigma delta ADC), to monitor temperature. Then just add in the standard single cog serial, and One Pin TV text, then it should be complete, just a matter of working through to get everything working correctly together.
The native commands have changed a little from the first posting of them. The native commands are now:
'Command processor. 'This uses a simple set of byte commands. {The Commands are one byte folowed by one or two bytes of data. The current commands are: 00nnnn = Move X, forward. 01nnnn = Move Y forward. 02nnnn = Move Z forward. 04nnnn = Move X reverse. 05nnnn = Move Y reverse. 06nnnn = Move Z reverse. 08nn = Set Current X Speed. 09nn = Set Current Y Speed. 0Ann = Set Current Z Speed. 0Bnn = Set Current Extrusion Speed. 0Fnn = Set Current Extruder Temperature. 10 = Zero X. 11 = Zero Y. 12 = Zero Z 14 = Set current X position as Zero. 15 = Set current Y position as Zero. 16 = Set current Z position as Zero. 18nnnn = Set current X position as nnnn. 19nnnn = Set current Y position as nnnn. 1Annnn = Set current Z position to nnnn. 1Cnnnn = Set Maximum X position to nnnn. 1Dnnnn = Set Maximum Y position to nnnn. 1Ennnn = Set Maximum Z position to nnnn. 20nn = Select Extruder. 21nn = Set Current Feed Rate. 22nn = Set Heat for current Extruder. 30 = Set Simulation Mode (does all the X/Y/Z movements, with the extruder turned off). 31 = UnSet Simulation Mode (back to regular print mode). 80nnnn = Set repeat counter. 81nnnn = Decrease repeat counter by one and go back up to 65535 bytes if repeat counter not zero. 84nn = Set small repeat counter. 85nn = Decrease Small Repeat Counter and go back up to 255 bytes if small repeat counter is not zero. F0 = All Stop. FF = Print Done (Turn off extruder(s), zero X and Y, move Z to maximum).. }as extracted from the comments that I am attempting to keep up to date with the code.This is a result of attempting to reduce memory usage for buffering commands. G-Code is huge compared to these commands to do the same thing.
The repeat commands ($80 and $81) are to save even more space where two or more layers are identical.
In G-Code the calibration cube is 46,710 bytes in size.
It will be a 0.0.1 do to not yet having a G-Code processor (only uses the native command language), and no serial communications.
The next step will be to add the G-Code interpreter, and then serial communication in a way that is compatible with standard 3D printer software. The first version of the G-Code interpreter will have to convert the entire sequence into native command code, it will be later extended to allow for better dynamic upload of stuff (as done in most 3D printers that usually have less than 4KB of data ram to work with), and allow for G-Code that converts to native Code larger than 16KB (the space allocated for the native code buffer), though I expect that to be rare.
I am also going to have to figure out a way to allow for uploading either G-Code or native code to the Propeller. That will be interesting, especially with out breaking compatibility.