That doesn't make any sense - double check that the file being written to has the same name as the one being read from. If they were different that would explain it.
Jason...Additional information. I changed the write file name to match the read file name so both are plasma.bin and the program output only 012E then stopped.
I changed the write file name back to plasma.txt and got the output 012E. I recycled power and the program output 012E. I reloaded the saved program and the output remained the same 012E.
It appears that something has changed in the SD memory due to changing the file name to plasma.bin.
Dave...No since there is no port on any of my computers that can handle the SanDisk micro memory. There is one port that handles the large SanDisk 32 gigabyte memory.
New Test Data...The SD memory was erased. The fopen() instruction in Jason's read code was changed to .txt and 1,000,000 nibbles were written to the SD memory.
The program ran fine.
Reading the memory files showed:
PLASMA Test file 977 kB
X.AXI 0 kB
The SD memory was erased and 2,000,000 nibbles were written to SD memory.
The program ran fine.
Reading the memory files showed:
PLASMA Test file 1,953 kB
X.AXI 0 kB
The SD memory was not erased and 500,000 nibbles were written to the SD memory.
The program ran fine.
Reading the memory files showed:
PLASMA Test file 488 kB
X.AXI 0 kB
The fopen instruction does indeed over write the file name with no problem.
The program is back to normal and I can now address getting my step and direction nibbles into the Buffer[0] block write to SD memory.
Oops...Not so fast. The current code can write Buffer[0] to the memory very fast but changing Jason's fopen() instruction to .txt caused the motors to turn extremely slowly. There appears to be some sensitivity to writing to memory with .txt or .bin and reading the memory with .txt or .bin.
The first fopen() call is opening a file called "filename.ext" for writing.
The second fopen() call is opening a file "filename.bla" for reading.
They aren't the same file if they don't have the same name, including the extension.
If you're altering the 2nd call to open "filename.txt", but not SIMULTANEOUSLY altering the first call to CREATE "filename.txt", you're not working with the same file in both places.
Are you only changing one of the fopen calls, or both? It wasn't clear from your message. They have to use the same filename AND extension.
Test (1) .txt write to memory, .txt read of memory to motors
Fast write to memory, very slow turn of motors
fopen("plasma,txt", "wr"); write to memory
Buffer[0]...
fwrite(Buffer[0]...
if
if
fopen("plasma.txt", "rb"); read memory and turn motors
Test(2) .bin write to memory, .bin read of memory to motors
Fast write to memory, very slow turn of motors
fopen("plasma.bin", "wb");
Buffer[0]...
fopen("plasma.bin", "rb"); read memory and turn motors
Test(3) .bin write to memory, .bin read memory and turn motors
Slow writing to memory (2 minutes 15 seconds for 200,000 nibbles, fast turn of motors
char byteToOutput = (1<<0) |(1<<1)|(1<<2)||(1<<3);
fwrite(&byteToOutput,1,1,fp);
byteToOutput = (0<<0)|(0<<1)|(0<<2)|(0<<3);
fwrite((&byteToOutput,1,1,fp
Test (1) .txt write to memory, .txt read of memory to motors
Fast write to memory, very slow turn of motors
fopen("plasma,txt", "wr"); write to memory
Buffer[0]...
fwrite(Buffer[0]...
if
if
fclose(fp);
fopen("plasma.txt", "rb"); read memory and turn motors
fclose(fp);
Test(2) .bin write to memory, .bin read of memory to motors
Fast write to memory, very slow turn of motors
fopen("plasma.bin", "wb");
Buffer[0]...
fclose(fp);
fopen("plasma.bin", "rb"); read memory and turn motors
fclose(fp);
Test(3) .bin write to memory, .bin read memory and turn motors
Slow writing to memory (2 minutes 15 seconds for 200,000 nibbles, fast turn of motors
fopen("plasma.bin", "wb");
char byteToOutput = (1<<0) |(1<<1)|(1<<2)||(1<<3);
fwrite(&byteToOutput,1,1,fp);
byteToOutput = (0<<0)|(0<<1)|(0<<2)|(0<<3);
fwrite(&byteToOutput,1,1,fp);
fclose(fp);
Without complete code it's very hard to determine what's causing your issues, but I suspect it's the data itself, not the reader / writer.
First things first:
fopen ("filename", "wr") is not a valid file mode. "w", "wb", "r", "rb" - all of these are good. "wr" - not good.
They are, in turn: "w" write access, text. "wb" write access, binary. "r" read access, text. "rb" read access, binary.
When operating in "text" mode the system assumes that an ascii value of 0 in the stream is a termination character. In binary mode, ascii values of 0 are treated no differently. You want binary mode.
Next:
The data itself is driving your motors. You're using stepper drivers that take pulses. If you write a sequence to the file that contains nothing but a static value written repeatedly, you're not toggling the motor pins, so they won't spin. How fast you are able to write to the file is completely independent of the data you are writing to that file. The rate and direction your motors spin is a direct result of the data being written to the file, so if that data is not consistent across your various means of testing the writes / reads, there's no reason to assume any correlation. If you want the motors to spin fast, leave the x & y direction pins alone, and toggle the x & y step pin values with each byte you output, whether it's in the buffered version or the "single write at a time" version.
I really can't shake the feeling that I'm being punked here.
//Write data to SD memory
fp = fopen("plasma.bin", "wb"); // Open a file for writing
for(i=0;i<4000000;i++)
{
char byteToOutput = 0; // start with all pins cleared, but...
if( i & 1 ) { // ...on every other iteration....
byteToOutput = (1<<1) | (1<<3); // ...toggle JUST the step pins
}
Buffer[0][ i & 511] = byteToOutput; // Use the first 512-byte buffer to hold data until it's full....
if( (i & 511) == 511 ) { // when we get to the end of the 512 bytes (0 to 511)
fwrite( Buffer[0], 1, 512, fp ); // ....write it to the SD card all at once
}
if( (i&16383) == 16383 ) { // display some output to the screen so we know it's working...
printi( "writing... %d\r", i );
}
}
fclose(fp);
// later....
fp = fopen("plasma.bin", "rb"); // Open the same file for reading
Jason...The "wr" in my message to you was just a type "O"...
As you will note in test three, all four bits are alternately set HIGH and LOW generating clocking pulses for xStep and yStep. The xDir and yDir signals are not used. Inputs to the motors are wired to zero volts. For testing, I am just interested in getting the 53,000 clockingRate to the motors.
In my version the pins are assumed as follows:
0 : XDir
1 : XStep
2 : YDir
3 : YStep
Technically the code doesn't care - it's just pulling the bottom 4 bits off each byte read from the file and sending them through pins 0 to 3 on the Prop, but the above is the convention I've been using during testing.
Now, when you say "all four bits are alternately set", to me that sounds like it includes the direction bits, unless you have four motors instead of two... ?
Jason...I set and clear all four bits to verify they are functioning from the memory read code. Only xStep and yStep outputs drive the motors. The xDir and yDir outputs are not sent to the motors. These signals are wired to zero volts. I am only interested in verifying that the 53 kHz clockRate drives the motors at this time. One step at a time.
This is the CodeChecker(4).c file you posted. I changed the print() statements to printi() statements (integer only, uses less memory), and that's it. Keep in mind that 26.5 kHz is the cycle time for a high pulse + a low pulse. That is single bytes output at 53kHz exactly.
Compiled in LMM mode:
Exactly as advertised.
Compiled in CMM mode:
Also exactly as advertised.
I'm not sure what's happening on your end, but it is most certainly on your end.
The file name and extension of your reads have to be exactly the same as for your writes for this to work. If you write the data to test.bin you must read from test.bin to read back that data.
Jason...I am pleased to see the code working on your machine. Late last night, I ran your code and after 3 and a half minutes I figured that it wasn't working and shutdown. I should have waited 4 minutes since this morning I let it run and at the 4 minute mark...the code ran perfectly.
I removed the writing statement and the memory load time was reduced to 3 minutes and 40 seconds for 4 mega nibbles which is really good. That represents a large amount of continuous cutting. I also increased the outputRate from 53 kHz to 60 kHz and the motors really turn fast. I estimate that the cutting head is moving about 6 times faster (maybe more) than your YouTube presentation drafting machine plotting head.
Thank you very much Jason. Now I have to get my nibble patterns loaded into the SD memory to complete the next upgrade.
Comments
Recycling electrical power to the Propeller Activity Board does not clear the problem. Two minutes and forty-five seconds worth of data are output.
Discovery
I changed the write file name back to plasma.txt and got the output 012E. I recycled power and the program output 012E. I reloaded the saved program and the output remained the same 012E.
It appears that something has changed in the SD memory due to changing the file name to plasma.bin.
Discovery
Discovery
Jim
Discovery
PLASMA.BIN 1k
PLASMA 1k
TEST 16k
X.AXI 4,194,304 kB
Discovery
Discovery
The program ran fine.
Reading the memory files showed:
PLASMA Test file 977 kB
X.AXI 0 kB
The SD memory was erased and 2,000,000 nibbles were written to SD memory.
The program ran fine.
Reading the memory files showed:
PLASMA Test file 1,953 kB
X.AXI 0 kB
The SD memory was not erased and 500,000 nibbles were written to the SD memory.
The program ran fine.
Reading the memory files showed:
PLASMA Test file 488 kB
X.AXI 0 kB
The fopen instruction does indeed over write the file name with no problem.
The program is back to normal and I can now address getting my step and direction nibbles into the Buffer[0] block write to SD memory.
Discovery
Discovery
The first fopen() call is opening a file called "filename.ext" for writing.
The second fopen() call is opening a file "filename.bla" for reading.
They aren't the same file if they don't have the same name, including the extension.
If you're altering the 2nd call to open "filename.txt", but not SIMULTANEOUSLY altering the first call to CREATE "filename.txt", you're not working with the same file in both places.
Are you only changing one of the fopen calls, or both? It wasn't clear from your message. They have to use the same filename AND extension.
Test (1) .txt write to memory, .txt read of memory to motors
Fast write to memory, very slow turn of motors
fopen("plasma,txt", "wr"); write to memory
Buffer[0]...
fwrite(Buffer[0]...
if
if
fopen("plasma.txt", "rb"); read memory and turn motors
Test(2) .bin write to memory, .bin read of memory to motors
Fast write to memory, very slow turn of motors
fopen("plasma.bin", "wb");
Buffer[0]...
fopen("plasma.bin", "rb"); read memory and turn motors
Test(3) .bin write to memory, .bin read memory and turn motors
Slow writing to memory (2 minutes 15 seconds for 200,000 nibbles, fast turn of motors
char byteToOutput = (1<<0) |(1<<1)|(1<<2)||(1<<3);
fwrite(&byteToOutput,1,1,fp);
byteToOutput = (0<<0)|(0<<1)|(0<<2)|(0<<3);
fwrite((&byteToOutput,1,1,fp
Test (1) .txt write to memory, .txt read of memory to motors
Fast write to memory, very slow turn of motors
fopen("plasma,txt", "wr"); write to memory
Buffer[0]...
fwrite(Buffer[0]...
if
if
fclose(fp);
fopen("plasma.txt", "rb"); read memory and turn motors
fclose(fp);
Test(2) .bin write to memory, .bin read of memory to motors
Fast write to memory, very slow turn of motors
fopen("plasma.bin", "wb");
Buffer[0]...
fclose(fp);
fopen("plasma.bin", "rb"); read memory and turn motors
fclose(fp);
Test(3) .bin write to memory, .bin read memory and turn motors
Slow writing to memory (2 minutes 15 seconds for 200,000 nibbles, fast turn of motors
fopen("plasma.bin", "wb");
char byteToOutput = (1<<0) |(1<<1)|(1<<2)||(1<<3);
fwrite(&byteToOutput,1,1,fp);
byteToOutput = (0<<0)|(0<<1)|(0<<2)|(0<<3);
fwrite(&byteToOutput,1,1,fp);
fclose(fp);
fopen("plasma.bin", "rb");
fclose(fp);
Discovery
Discovery
First things first:
fopen ("filename", "wr") is not a valid file mode. "w", "wb", "r", "rb" - all of these are good. "wr" - not good.
They are, in turn: "w" write access, text. "wb" write access, binary. "r" read access, text. "rb" read access, binary.
When operating in "text" mode the system assumes that an ascii value of 0 in the stream is a termination character. In binary mode, ascii values of 0 are treated no differently. You want binary mode.
Next:
The data itself is driving your motors. You're using stepper drivers that take pulses. If you write a sequence to the file that contains nothing but a static value written repeatedly, you're not toggling the motor pins, so they won't spin. How fast you are able to write to the file is completely independent of the data you are writing to that file. The rate and direction your motors spin is a direct result of the data being written to the file, so if that data is not consistent across your various means of testing the writes / reads, there's no reason to assume any correlation. If you want the motors to spin fast, leave the x & y direction pins alone, and toggle the x & y step pin values with each byte you output, whether it's in the buffered version or the "single write at a time" version.
I really can't shake the feeling that I'm being punked here.
//Write data to SD memory fp = fopen("plasma.bin", "wb"); // Open a file for writing for(i=0;i<4000000;i++) { char byteToOutput = 0; // start with all pins cleared, but... if( i & 1 ) { // ...on every other iteration.... byteToOutput = (1<<1) | (1<<3); // ...toggle JUST the step pins } Buffer[0][ i & 511] = byteToOutput; // Use the first 512-byte buffer to hold data until it's full.... if( (i & 511) == 511 ) { // when we get to the end of the 512 bytes (0 to 511) fwrite( Buffer[0], 1, 512, fp ); // ....write it to the SD card all at once } if( (i&16383) == 16383 ) { // display some output to the screen so we know it's working... printi( "writing... %d\r", i ); } } fclose(fp); // later.... fp = fopen("plasma.bin", "rb"); // Open the same file for readingAs you will note in test three, all four bits are alternately set HIGH and LOW generating clocking pulses for xStep and yStep. The xDir and yDir signals are not used. Inputs to the motors are wired to zero volts. For testing, I am just interested in getting the 53,000 clockingRate to the motors.
I don't understand "punked".
I will checkout you code above shortly.
Discovery
0 : XDir
1 : XStep
2 : YDir
3 : YStep
Technically the code doesn't care - it's just pulling the bottom 4 bits off each byte read from the file and sending them through pins 0 to 3 on the Prop, but the above is the convention I've been using during testing.
Now, when you say "all four bits are alternately set", to me that sounds like it includes the direction bits, unless you have four motors instead of two... ?
Your code had a compile error fp = fopen("plasma.bin"... [First use of the term]
I changed it to FILE * fp = ... and it compiled and ran producing written numbers on the screen with no data on output pins (0,1,2,3).
The "c" code is attached.
Discovery
Discovery
Compiled in LMM mode:
Exactly as advertised.
Compiled in CMM mode:
Also exactly as advertised.
I'm not sure what's happening on your end, but it is most certainly on your end.
The file name and extension of your reads have to be exactly the same as for your writes for this to work. If you write the data to test.bin you must read from test.bin to read back that data.
I removed the writing statement and the memory load time was reduced to 3 minutes and 40 seconds for 4 mega nibbles which is really good. That represents a large amount of continuous cutting. I also increased the outputRate from 53 kHz to 60 kHz and the motors really turn fast. I estimate that the cutting head is moving about 6 times faster (maybe more) than your YouTube presentation drafting machine plotting head.
Thank you very much Jason. Now I have to get my nibble patterns loaded into the SD memory to complete the next upgrade.
This is really superb!
Discovery