Originally you never got an image. With your help I traced this to: - incorrect wiring - a faulty 0V7670The fact that you are now getting an image with this second 0V7670 indicates that your circuit is working.But the cause of the horizontal bands is a mystery. These horizontal bands appear to contain faint image information (especially your second curtain photo) which suggests that the Arduino is missing an occasional PCLK signal. If this were to happen then you would see the UV color components of the image which, if you look at photo 1 in step 8 of this instructable, only contains faint image information. The image would return to normal if another PCLK signal was missed.To test this PCLK theory we have tried: - swapping the PCLK input to Arduino pin 12 in the off-chance that pin 8...

Originally you never got an image. With your help I traced this to: - incorrect wiring - a faulty 0V7670The fact that you are now getting an image with this second 0V7670 indicates that your circuit is working.But the cause of the horizontal bands is a mystery. These horizontal bands appear to contain faint image information (especially your second curtain photo) which suggests that the Arduino is missing an occasional PCLK signal. If this were to happen then you would see the UV color components of the image which, if you look at photo 1 in step 8 of this instructable, only contains faint image information. The image would return to normal if another PCLK signal was missed.To test this PCLK theory we have tried: - swapping the PCLK input to Arduino pin 12 in the off-chance that pin 8 was level sensitive - a faster method of sending dataThe only thing I can think of now is some form of instability which can be caused by - lead length - proximity of critical leads to anotherCan you please send a photo of your camera. I need to see your construction layout before I can make any further suggestions.

If you study the photo in Step 3 of this instructable you will see how it is broken up into three sets of information.The desired "Y" information, which appears every second data position, produces a detailed image. This us why we sample the data every second PCLK.The unwanted "U" and "V" information only contains faint images. These signals, if displayed on a monochrome screen, would appear as faint monochrome outlines.If you now examine each of your three "window" images you can see faint outlines in each of the unwanted horizontal bands. It would appear that your Arduino is not detecting the occasional PCLK signal from your 0V7670 chip. If this were to happen then every second sample would become "U" then "V" information and...

If you study the photo in Step 3 of this instructable you will see how it is broken up into three sets of information.The desired "Y" information, which appears every second data position, produces a detailed image. This us why we sample the data every second PCLK.The unwanted "U" and "V" information only contains faint images. These signals, if displayed on a monochrome screen, would appear as faint monochrome outlines.If you now examine each of your three "window" images you can see faint outlines in each of the unwanted horizontal bands. It would appear that your Arduino is not detecting the occasional PCLK signal from your 0V7670 chip. If this were to happen then every second sample would become "U" then "V" information and the image would appear as faint monochrome outlines until another PCLK signal is missed at which point the desired image will reappear. This would also explain the slanted edges to each of your images as the frame-grabber is a dumb device and simply captures data until a linefeed symbol is received at which point it will display the data it has received.It would appear that:(1) your frame-grabber is working correctly(2) your 0V7670 camera chip is working.(3) your 5 volt Arduino is not reliably detecting the PCLK signals from the 3 volt 0V7670 CMOS camera chipThings to try:(1) Swap your existing Arduino board for another. Make certain you PROGRAM IT FIRST before attaching the OV7670 wires.(2) If you don't have a spare Arduino board then you could try mapping the PCLK signal to another unused Arduino pin ... some pins may be more sensitive. If you do this then you will need to change the binary patterns, and possibly ports numbers, in each of the code lines associated with the PCLK signal. Let me know if you need help with this.

An image at last ... well done :)The fact that you are now getting an image indicates that both your camera module and frame grabber are working.I am a little puzzled about your images as I have not encountered this problem. Both images have a slanting edge which indicates a timing / synchronising issue. In particular the lower part of your first image appears to "wrap-around" the screen.The "bands" in each image also indicate a loss of sync. I suspect that you are occasionally loosing a sync pulse and what you are seeing are bands of "UV" (color) data then "Y" (image) data as you regain sync. If this problem occurs at start up then it may resolve after running for a while (I'm thinking temperature).Go back over my previous suggestions ... in part...

An image at last ... well done :)The fact that you are now getting an image indicates that both your camera module and frame grabber are working.I am a little puzzled about your images as I have not encountered this problem. Both images have a slanting edge which indicates a timing / synchronising issue. In particular the lower part of your first image appears to "wrap-around" the screen.The "bands" in each image also indicate a loss of sync. I suspect that you are occasionally loosing a sync pulse and what you are seeing are bands of "UV" (color) data then "Y" (image) data as you regain sync. If this problem occurs at start up then it may resolve after running for a while (I'm thinking temperature).Go back over my previous suggestions ... in particular the answer in which I post six images.

The fact that you are getting a dark image indicates that the lighting levels have changed in which case you wiwll need to increase the camera gain.Since the picture also exhibits the same problems as your previous post I suggest that you concentrate on getting a stable image using the settings for your window shots before changing the lighting.

I can understand your frustration. Keep in mind that I cannot see what you are doing and have no way of knowing what you have tried in an attempt to debug your latest problem ... you are my eyes and ears. Sounding off does not help.Currently you have progressed from no image to a (slightly) distorted image.Together we isolated your initial lack of an image to a faulty OV7670.I am assuming that you have confirmed that the framegrabber is working by performing the tests that I have previously sent you. I am attaching the three screen shots again. Your framegrabber screen should change from light-gray, to gray, and then to black when you change the Serial.print(data); line in yellow-high light. This test is probably unnecessary as you are now getting an image. Restore the line in yellow-h...

I can understand your frustration. Keep in mind that I cannot see what you are doing and have no way of knowing what you have tried in an attempt to debug your latest problem ... you are my eyes and ears. Sounding off does not help.Currently you have progressed from no image to a (slightly) distorted image.Together we isolated your initial lack of an image to a faulty OV7670.I am assuming that you have confirmed that the framegrabber is working by performing the tests that I have previously sent you. I am attaching the three screen shots again. Your framegrabber screen should change from light-gray, to gray, and then to black when you change the Serial.print(data); line in yellow-high light. This test is probably unnecessary as you are now getting an image. Restore the line in yellow-highlight to read Serial.print(data); when you have finished.The number 307201 should be displayed following each test.Assuming that the framegrabber tests okay you need to figure out why your data is getting corrupted.For this project to work you need relatively short leads as we are dealing with microsecond pulse widths. Long leads can distort pulses which could cause pulses to be missed which will result in a distorted image. If you look at my wiring the earth and supply leads are extremely short.

I have not tried an XC4492 so am unable to comment.Big Easy Drivers are specifically designed for the motor configuration in this project. Specifically they feature: - a single direction pin - a single step pin - adjustable current limitUnless the XC4492 has these features I suggest that you replicate my design as Big Easy Drivers are readily available and extremely cheap.Good luck with your project :)

Any 12 volt DC power adapter capable of 1 amp should be fine providing that you adjust each motor current to 400 milliamps (0.4 amps) as described in Step 1, "Adjusting the motor current(s)". Since power adapters do not have an inbuilt current meter you will need to (temporarily) insert an amp-meter in series with the power supply while you adjust each of the Big Easy Driver current limits to 0.4 amps (400 milliamps). Before adjusting the Big Easy Driver currents use an ohm-meter to check that each of the two motor coil windings are adjacent to each other on the Big Easy Driver boards.The 12 volt supply is ONLY connected to the Big Easy Drivers as shown in the CoreXY Plotter wiring diagram. The 5 volts for the Arduino Uno R3 is obtained from the USB cable connected to your PC.

Thank you for taking the time to write this Instructable ... your sample epub is excellent :)In 2013 I wrote two books for Amazon Kindle. The software that I used wasn't really suited to illustrated books ... I wish that I had seen this article way back then as your method is so much simpler.

Correct. The video shows two objects being pin-pointed.In this instructable, as shown in step 3, four sensors create four detection areas which means that four separate objects may be detected providing that (1) each object is in a separate detection area and that (2) there is no "shadowing". In https://www.instructables.com/id/Dual-Sensor-Echo-Locator/ two sensors create a single detection area. To cover a given area the two sensors need to be offset below the baseline.Note that the sensors in this instructable are resting on the baseline whereas the two sensor version requires the sensors to be positioned below the baseline in order to completely illuminate the target area.

For some projects a servo provides a simpler, and cheaper, solution than a Z-axis motor and motor controller.I wrote this instructable as there is not a lot of information about using a servo with GRBL.An example of how this instructable has helped others may be found at https://github.com/WJonson/CNC-Object-Locator

Assuming that the "system" has been calibrated for temperature, humidity, and atmospheric pressure, the accuracy should approximate that of your sensors.Automatic calibration is possible using a third transducer (in the same environment) spaced a known distance from a separate reflector to calculate the correct value to use in place of the constants 59 and 29.5Without calibration the accuracy is within 1 or 2 centimeters depending on the shape of the object.

The write_register() function only expects two values.The first value is the register numberThe second value is the actual value to be written into the register.In my previous answer I have provided several screen shots.The photos showing light-gray, darker-gray, and black screens have the test code shown in yellow highlight. You should see the same if you enter these values ... regardless of the settings in the initialise_OV7670() function.These three tests simply confirm that your frame-grabber is working correctly.The photo showing a completely white screen shows what you should see when you try sending actual data to the framegrabber with all of the gain bits (shown in yellow high-light) set to '1'.The photo showing a perfect picture requires the initialise_OV7670() shown.Increasi...

The write_register() function only expects two values.The first value is the register numberThe second value is the actual value to be written into the register.In my previous answer I have provided several screen shots.The photos showing light-gray, darker-gray, and black screens have the test code shown in yellow highlight. You should see the same if you enter these values ... regardless of the settings in the initialise_OV7670() function.These three tests simply confirm that your frame-grabber is working correctly.The photo showing a completely white screen shows what you should see when you try sending actual data to the framegrabber with all of the gain bits (shown in yellow high-light) set to '1'.The photo showing a perfect picture requires the initialise_OV7670() shown.Increasing the gain from zero to 4 produces the over-exposed image.

The write_register() function only expects two values.The first value is the register numberThe second value is the actual value to be written into the register.In my previous answer I have provided several screen shots.The photos showing light-gray, darker-gray, and black screens have the test code shown in yellow highlight. You should see the same if you enter these values ... regardless of the settings in the initialise_OV7670() function.These three tests simply confirm that your frame-grabber is working correctly.The photo showing a completely white screen shows what you should see when you try sending actual data to the framegrabber with all of the gain bits (shown in yellow high-light) set to '1'.The photo showing a perfect picture requires the initialise_OV7670() shown.Increasing...

The write_register() function only expects two values.The first value is the register numberThe second value is the actual value to be written into the register.In my previous answer I have provided several screen shots.The photos showing light-gray, darker-gray, and black screens have the test code shown in yellow highlight. You should see the same if you enter these values ... regardless of the settings in the initialise_OV7670() function.These three tests simply confirm that your frame-grabber is working correctly.The photo showing a completely white screen shows what you should see when you try sending actual data to the framegrabber with all of the gain bits (shown in yellow high-light) set to '1'.The photo showing a perfect picture requires the initialise_OV7670() shown.Increasing the gain from zero to 4 produces the over-exposed image.*****************************************************************************************It would appear that you have previous attempted to make a camera as: (1) your PCLK, HREF, and VSYNC wiring was mapped to different pins(2) you were not using 4K7 pull-up resistors.(haven't tried but 10K is probably fine)In my article I stress, in several places, to upload my code to the arduino BEFORE

With regards to this camera project I have simply exhausted all possibilities, but feel free to ask for help with any of your other projects :)Thank you for your questions. In trying to find a solution I found that a minor change to one line of the processing code significantly improved the image quality. No changes were required to the Arduino code.Please note that, should you rebuild your camera: (1) OV7670_camera_mono_V2.pde and OV7670_camera_color_V2.pde both contain this code update. The Arduino code is unaltered but is renamed to V2 to match.(2) No code changes should be needed.(3) Upload the arduino code BEFORE attaching any wires to your OV7670 as 5 volts will destroy the chip.

A solution to your problem is discussed in "Step 8: Raising and Lowering Your Pen"."GPP.zip", attached to Step 8, contains a post-processor that should fix your issue.The GPP post-processor is designed to work with Inkscape which generates a "M2" stop code. Non-Inkscape gcode may use M30 ... in which case edit the source code to suit.

Your camera may well be working ... it may just need more gain.Overwrite any code changes that you may have made by reinstalling BOTH "OV7670_camera_mono.pde" and "OV7670_camera_mono.ino". -------------------------------------In the "OV7670_camera_mono.pde" software-------------------------------------Change code line 78 to read:pixels[i] = color(int(byteBuffer[i])); Explanation:Changing the data type SIGNIFICANTLY improves the image. -------------------------------------In the "OV7670_camera_mono.ino"-------------------------------------Your image brightness may be adjusted as as follows:Change the code to read:write_register(0x07, B00000000); write_register(0x10, B00100000);write_register(0x04, B00000000);Explanation:These three lines control th...

Your camera may well be working ... it may just need more gain.Overwrite any code changes that you may have made by reinstalling BOTH "OV7670_camera_mono.pde" and "OV7670_camera_mono.ino". -------------------------------------In the "OV7670_camera_mono.pde" software-------------------------------------Change code line 78 to read:pixels[i] = color(int(byteBuffer[i])); Explanation:Changing the data type SIGNIFICANTLY improves the image. -------------------------------------In the "OV7670_camera_mono.ino"-------------------------------------Your image brightness may be adjusted as as follows:Change the code to read:write_register(0x07, B00000000); write_register(0x10, B00100000);write_register(0x04, B00000000);Explanation:These three lines control the image brightness. You are allowed to write a '1' into any of the positions below that are shown with an 'x'write_register(0x07, Bxxxxxxxx); write_register(0x10, Bxxxxxxxx); write_register(0x04, B000000xx); The default position is"write_register(0x07, B00000000);write_register(0x10, B00100000); write_register(0x04, B00000000); Please let me know if this works and I will update the Instructable.A screenshot showing the changes is attached.

There is a strong possibility that your OV7670 is not working :(With a '1' written into every bit position your screen should be white as shown in Gain_high.jpg (attached) .... your screen is gray ???With a '0' written into every bit position you should get an image as shown in Gain_zero.jpg (attached).With a gain setting of 4 (binary 00000000 00000001 00) the image starts to over-expose as shown in Gain_four.jpg (attached).While you are getting valid sync pulses it appears that your OV7670 data lines are producing invalid data. A simple way of verifying this is to fill each bit position with a '1' (as you have done) and send known hexadecimal data values to your PC as shown in the remaining screen shots.0x00 produces a black screen as shown in Serial_write_0x00.jpg.0x80 produces a mid-...

There is a strong possibility that your OV7670 is not working :(With a '1' written into every bit position your screen should be white as shown in Gain_high.jpg (attached) .... your screen is gray ???With a '0' written into every bit position you should get an image as shown in Gain_zero.jpg (attached).With a gain setting of 4 (binary 00000000 00000001 00) the image starts to over-expose as shown in Gain_four.jpg (attached).While you are getting valid sync pulses it appears that your OV7670 data lines are producing invalid data. A simple way of verifying this is to fill each bit position with a '1' (as you have done) and send known hexadecimal data values to your PC as shown in the remaining screen shots.0x00 produces a black screen as shown in Serial_write_0x00.jpg.0x80 produces a mid-gray screen as shown in Serial_write_0x80.jpg.0xD0 produces a light-gray screen as shown in Serial_write_0xD0.jpg0xFF will produce a completely white screen.

The fact that you have data indicates that your hardware is working :)I suspect the problem is the result of too much light. If you pause the video in my Instructable at 0:14 seconds you will see that the room is dimly lit.In Step 4 (Design Notes: Side Effects) I mention "To prevent over-exposure I have set all of the AEC (auto exposure control) register bits to zero. Even so a neutral density filter is needed in front of the lens when the lighting is bright." The exposure values are set to minimum in the "initialise_OV7670(){}" subroutine should you wish to experiment.Try installing "OV7670_camera_mono.ino/pde" as this software is much faster which means that you can quickly see the effect of different light levels. The "color" software can be tr...

The fact that you have data indicates that your hardware is working :)I suspect the problem is the result of too much light. If you pause the video in my Instructable at 0:14 seconds you will see that the room is dimly lit.In Step 4 (Design Notes: Side Effects) I mention "To prevent over-exposure I have set all of the AEC (auto exposure control) register bits to zero. Even so a neutral density filter is needed in front of the lens when the lighting is bright." The exposure values are set to minimum in the "initialise_OV7670(){}" subroutine should you wish to experiment.Try installing "OV7670_camera_mono.ino/pde" as this software is much faster which means that you can quickly see the effect of different light levels. The "color" software can be tried once you have an image using the "mono" software. The "color" software requires the same lighting level ... it is essentially the "mono" software run twice then processed. Keep in mind the color "software is purely experimental" and that "the colors appear to be inverted".

If you haven't already done so, upload "OV7670_camera_mono.ino" to your Arduino.Do not make any changes to the code. If you have access to an oscilloscope you should see signals on each of the data lines.Open the Arduino "Serial|Monitor" and set the baud speed to 1000000.Remove the lens-cap from your OV7670 in bright light. Removing the lens cap forces the OV7670 data pattern to 255 (white)Now send the letter 'c' to your Arduino and note the symbols/characters that appear in the Serial|Monitor.Replace the lens-cap on your OV7670. Adding the lens cap forces the data pattern to be 0 (black)Send the letter 'c' to your Arduino and note the symbols/characters that appear the Serial|Monitor. These symbols/characters should be different.If no visible characters appear on th...

If you haven't already done so, upload "OV7670_camera_mono.ino" to your Arduino.Do not make any changes to the code. If you have access to an oscilloscope you should see signals on each of the data lines.Open the Arduino "Serial|Monitor" and set the baud speed to 1000000.Remove the lens-cap from your OV7670 in bright light. Removing the lens cap forces the OV7670 data pattern to 255 (white)Now send the letter 'c' to your Arduino and note the symbols/characters that appear in the Serial|Monitor.Replace the lens-cap on your OV7670. Adding the lens cap forces the data pattern to be 0 (black)Send the letter 'c' to your Arduino and note the symbols/characters that appear the Serial|Monitor. These symbols/characters should be different.If no visible characters appear on the screen substitute the following (untested) code in "OV7670_camera_mono.ino": /* Read second byte */ while (PINB & B00000001); // Wait until PCLK pin 8 is low data = (PIND & B11110000) | (PINC & B00001111); // Read data if (data <128) { Serial.write('A'); } else { Serial.write('Z'); } while (!(PINB & B00000001)); // Wait until PCLK pin 8 is highIf the characters change from 'AAAAAA....' to 'ZZZZZZZ.....' when you add/remove the lens cap your OV7670 is okay, in which case upload "OV7670_camera_mono.ino" once more to your Arduino and run the OV7670_camera_mono.pde" sketch on your PC. Point your OV7670 to a dimly lit object.An image should appear in the PC image window, and the number 307201 should appear in the bottom Processing window (307201 = 640*480 pixels + 1 termination character)whenever your press the 'c' key.Now adjust the lighting level to suit.The above tests should determine whether your OV7670 is working .

Thank you for the screen-shot of the "OV7670_camera_color" software.The light-gray screen indicates that the Processing 3 software is working correctly.It would appear that you have changed the wiring for "PCLK", "HREF", and "VSYNC". As a result no data is being sent to the PC.For my code to work the wiring should be as follows:/* OV7670 */#define OV7670 0x21 // OV7670 address#define PCLK 8 //pixel clock from OV7670#define HREF 9 //horizontal sync from 0V7670 (not used)#define VSYNC 10 //vertical sync from OV7670#define XCLK 11 //8MHz output to OV7670A wiring-diagram is included in my code header. I am using pins 8,9,10,11 for the following reasons: - I found pins 2,3 unreliable (e...

Thank you for the screen-shot of the "OV7670_camera_color" software.The light-gray screen indicates that the Processing 3 software is working correctly.It would appear that you have changed the wiring for "PCLK", "HREF", and "VSYNC". As a result no data is being sent to the PC.For my code to work the wiring should be as follows:/* OV7670 */#define OV7670 0x21 // OV7670 address#define PCLK 8 //pixel clock from OV7670#define HREF 9 //horizontal sync from 0V7670 (not used)#define VSYNC 10 //vertical sync from OV7670#define XCLK 11 //8MHz output to OV7670A wiring-diagram is included in my code header. I am using pins 8,9,10,11 for the following reasons: - I found pins 2,3 unreliable (external interrupt pin loading ???) - Grouping pins 8,9,19,11 together makes it easier to tape the wires in place.The same pinouts are used for the "OV7670_camera_mono.ino" and "OV7670_camera_color.ino" software.You can confirm that the Arduino code is working using the "Serial|Monitor".Set the Arduino Serial|Monitor baud speed to 1000000 and type "c" in the command window. The link light on the Arduino should flash then, after a few seconds, a string of strange characters should race across the screen. If you want to see a string of visible characters then (temporarily) change code lines 233,296 to read: Serial.write('A'); // Send data to PCOnce you see a string of "AAAAAAAAAAAAAAAAAA...'s" you know the code is working. Change the code back to Serial.write(data); and launch Processing 3 again.

The software for "Acoustic Radar Display" must be loaded in the following sequence:--------------------The Arduino software--------------------(1) Connect a USB cable between your Arduino and your PC(2) Click "Tools|Port" then select your Arduino serial port number.(3) Upload the Arduino sketch to your Arduino(4) Leave the USB plugged in to your PC(5) Close your Arduino IDE ... it is no longer required---------------------Processing 3 Software----------------------(1) Now run the Processing 3 sketch-----------------------Possible error messages------------------------You will get an error message if:(1) the Arduino USB cable is not plugged in to the PC.(2) The Processing serial port is not the same as that used to program the Arduino(3) The error message that you des...

The software for "Acoustic Radar Display" must be loaded in the following sequence:--------------------The Arduino software--------------------(1) Connect a USB cable between your Arduino and your PC(2) Click "Tools|Port" then select your Arduino serial port number.(3) Upload the Arduino sketch to your Arduino(4) Leave the USB plugged in to your PC(5) Close your Arduino IDE ... it is no longer required---------------------Processing 3 Software----------------------(1) Now run the Processing 3 sketch-----------------------Possible error messages------------------------You will get an error message if:(1) the Arduino USB cable is not plugged in to the PC.(2) The Processing serial port is not the same as that used to program the Arduino(3) The error message that you describe indicates that you have tried to upload software to your Arduino while the Processing sketch is running.

The method I devised for plotting arcs is explained in "Step 11" of https://www.instructables.com/id/CNC-Drum-Plotter/ Two identical triangles are formed when you bisect a chord drawn between the start and end points on a circle. The angle at the center of the circle can now be calculated using trigonometery. The arc-length can then be calculated using the formaula arc=angle*radius.If the start and end points are close together then each chord lies on the arc. My solution is to calculate the target arc-length, divide it into a number of smaller lengths (this makes each chord lie on the arc) and calculate the intermediate end points. The last intermediate point is connected to the target end-point.

See note [1] in "Step 3: Modifying GRBL".A copy of "spindle_control.c" is included there ...

The "spindle_control.c" file in Step 3 expects GRBLversion 1.1f.You are using an earlier version ... Some suggestions:(1) Install GRBL version 1.1f and try again(2) Check your wiring as it is unusual for a servo to overheat

"How can I learn the CNC programming for a cd drive turned 2d plotter .......I can't understand the codes in arduino and processing. Could you please help me."--------------------------------------"How can I learn the CNC programming"--------------------------------------The following link may be helpful:https://makezine.com/2016/10/24/get-to-know-your-cnc-how-to-read-g-code/There are many codes ... fortunately you only need to know a few.Codes that refer to positioning start with the letter 'G' ... they tell the machine where to go and how to get there.Examples:(1) G00 X100 Y150 = Go (rapidly with your pen up) to location X=100, Y=150(2) G01 X100 Y150 = Go (slowly with your pen down) to location X=100, Y=150(3) G02 X100 Y150 = Go clockwise (with your pen down) to l...

"How can I learn the CNC programming for a cd drive turned 2d plotter .......I can't understand the codes in arduino and processing. Could you please help me."--------------------------------------"How can I learn the CNC programming"--------------------------------------The following link may be helpful:https://makezine.com/2016/10/24/get-to-know-your-cnc-how-to-read-g-code/There are many codes ... fortunately you only need to know a few.Codes that refer to positioning start with the letter 'G' ... they tell the machine where to go and how to get there.Examples:(1) G00 X100 Y150 = Go (rapidly with your pen up) to location X=100, Y=150(2) G01 X100 Y150 = Go (slowly with your pen down) to location X=100, Y=150(3) G02 X100 Y150 = Go clockwise (with your pen down) to location X=100, Y=150(4) G03 X100 Y100 = Go CCW (with your pen down) to location X=100, Y=150Codes that start with the letter 'M' are general machine instructions.Examples:(1) M0 = Stop(2) M2 = Program End(3) M3 = Spindle On (Clockwise)(4) M4 = Spindle On (Counterclockwise)-----------------------------------------------------------------------With regards to "I can't understand the codes in arduino and processing"-----------------------------------------------------------------------Arduino, and Processing, programs both use the C, C++ language.If you have never written an arduino program then I recommend purchasing a copy of "Programming Arduino: Getting Started with Sketches", Second Edition, 2016by Simon Monk.The C & C++ languages do not use Gcode, but it is possible to a write program in C/C++, such as interpreter, that intercepts Gcode sent to it and makes your plotter perform the requested action.Such a program is GRBL ... see my instructable https://www.instructables.com/id/How-to-Control-a-Servo-Using-GRBL/ which includes instructions on how to create Gcode from a drawing.

Assuming that you have constructed my "COREXY CNC PLOTTER" described in https://www.instructables.com/id/CoreXY-CNC-Plotter/:(1)Check that your wiring matches that in the photo "GRBL Servo Wiring" in the Intro section of https://www.instructables.com/id/How-to-Control-a-Servo-Using-GRBL/.(2)Delete your C:\Documents\Arduino\libraries\grbl1.1f_servo library.(3)Now reinstall your C:\Documents\Arduino\libraries\grbl1.1f_servo library.(4)It is important that you use a text editor, such as Notepad++, to uncomment line 189 in the file “spindle_control.c” in your C:\Documents\Arduino\libraries\grbl1.1f_servo folder. Do NOT use a word processor.Providing you follow each step in "Step 3: Modifying GRBL" your plotter should work.

One way to disconnect your computer would be to use the SD card slot on your PC and add bluetooth as described in my instructable https://www.instructables.com/id/Add-Bluetooth-to-...But if you want a completely self contained plotter you will need to add an SD card reader module to the plotter and write the necessary code. An LCD display would also be helpful.A self contained plotter is plausible but if I were to go down this track I would modify my https://www.instructables.com/id/CoreXY-CNC-Plotte... plotter as - that plotter is significantly more accurate [1] - plus the paper is easier to load and unload - and the design is scalable[1] See my comment to DejayRezme in the comment section for https://www.instructables.com/id/CNC-Drawing-Arm/ which is also an angle-distance plotter.

The error message indicates that you may have accidentally added/deleted something while in edit mode. Providing you only delete the "//" comment in line 189 , as shown in slide 3, Step 3, everything should compile.Try this:(1) Delete and reinstall a fresh copy of spindle_control.c. (2) Does it compile ? (3) If so, edit line 189 as shown in Step 3, slide 3(4) If not, the problem is elsewhere ... check that you have GRBLversion 1.1fAll going well it should compile....

My first approach would be to replace the USB cable with a two way wireless link. The following tutorials:https://www.instructables.com/id/Arduino-wireless-... https://www.instructables.com/id/Interfacing-OLED-...may be helpful.

TeraTerm is a PC application available from https://osdn.net/projects/ttssh2/releases/A list of all code, and installation instructions, may be found in Step 6 of this instructable.An alternate terminal program that is specifically designed to work with my plotters may be found at https://www.instructables.com/id/CNC-Gcode-Sender/. I recommend using this application as it is able to transfer data at a higher rate which significantly reduces your plot times.

In order to help I need further information:(1) What operation?(2) This terminal program will (unless modified) only work with my plotters. Are you attempting to talk to one of my plotters or are you connected to a 3rd-party plotter?(3) All of my plotters respond with a menu. Did a "menu" and a "grey box" appear? (4) Your screen indicates that you have something attached to your serial port (as there is no error message). Does your serial baud speed match your plotter?

Hi,A zipped version of the (original) LiquidCrystal_I2C library is attached. Thanks for drawing my attention to the fact that the original libraries have been updated.Look forward to seeing your code updates.

Hi,This is the only other library that I can find. The files are dated 1/05/2017 ... hopefully this is what you are looking for.

The time interval for sensor A is from when Echo line A goes high until Echo line A goes low.Similarly the time interval for sensor B is from when Echo line B goes high until Echo line B goes low.The Echo lines only go high when the sensors receive a trigger pulse. For the system to work we must trigger BOTH sensors together.The ping from sensor B is not heard by sensor A as the transmit pulse is blocked by the addition of masking tape over the transmit sensor B.If you examine the Arduino code you will see that I quickly trigger each sensor in turn then wait until both Echo lines have gone high.The reason for waiting is that there is a considerable delay after a Trig pulse before the Echo line go high ... see the waveforms in my article https://www.instructables.com/id/Enhanced-Ultrason...

The time interval for sensor A is from when Echo line A goes high until Echo line A goes low.Similarly the time interval for sensor B is from when Echo line B goes high until Echo line B goes low.The Echo lines only go high when the sensors receive a trigger pulse. For the system to work we must trigger BOTH sensors together.The ping from sensor B is not heard by sensor A as the transmit pulse is blocked by the addition of masking tape over the transmit sensor B.If you examine the Arduino code you will see that I quickly trigger each sensor in turn then wait until both Echo lines have gone high.The reason for waiting is that there is a considerable delay after a Trig pulse before the Echo line go high ... see the waveforms in my article https://www.instructables.com/id/Enhanced-Ultrason...The point at which both Echo lines go high is defined as my start point ... the slight time difference between Trig pulses is not significant.This time difference, however, may be eliminated by writing a "pattern" to the output port. An example of this technique may be found in my instructable https://www.instructables.com/id/CoreXY-CNC-Plotte...

The time interval for sensor A is from when Echo line A goes high until Echo line A goes low. See the waveforms in my article https://www.instructables.com/id/Enhanced-Ultrason...Similarly the time interval for sensor B is from when Echo line B goes high until Echo line B goes low.The Echo lines only go high when the sensors receive a trigger pulse. For the system to work we must trigger BOTH sensors together.The ping from sensor B is not heard by sensor A as the transmit pulse is blocked by the addition of masking tape over the transmit sensor B.

The beam-width of an ultrasonic sensor is approximately 30 degrees ... think of this as, say, 100 individual beams each at a slightly different angle to the one next to it.In physics the "angle-of-incidence" equals the "angle-of-reflection" on the opposite side of a "perpendicular" drawn at the point of reflection. Ultrasonic "radar-like" displays using a servo only see the the beam that gets reflected directly back (along the perpendicular)... the other 99 beams get lost.This detector uses the same principle. Sensor A sees the beam that gets reflected directly back ... the other 99 beams each get reflected at slightly different angles.Sensor B sees one of these 99 reflected beams ... the other 98 beams get lost.Photo 2 in Step 3 shows a diagra...

The beam-width of an ultrasonic sensor is approximately 30 degrees ... think of this as, say, 100 individual beams each at a slightly different angle to the one next to it.In physics the "angle-of-incidence" equals the "angle-of-reflection" on the opposite side of a "perpendicular" drawn at the point of reflection. Ultrasonic "radar-like" displays using a servo only see the the beam that gets reflected directly back (along the perpendicular)... the other 99 beams get lost.This detector uses the same principle. Sensor A sees the beam that gets reflected directly back ... the other 99 beams each get reflected at slightly different angles.Sensor B sees one of these 99 reflected beams ... the other 98 beams get lost.Photo 2 in Step 3 shows a diagram of the two beam paths and the equations for determining the X and Y coordinates relative to sensor A

Possibly ,,, but I can't answer as I don't have one to experiment with.I searched the internet to find circuit diagrams for the HC-SR04 and Hy-SRF05 ultrasonic sensors. To my surprise I came up with four different circuits depending on the manufacturer.All circuits were similar but required a bit of oscilloscope probing to find a suitable point for attaching the wire. I avoid soldering to copper track as that has virtually no "peel strength".

Probably not as we are al[ using different ISP'sMy guess is that it's a coding issue ... I flagged this issue as a potential "bug" but so far have had no acknowledgement that they are aware of the issue.

Check that:(1) Check that the link on the ULN2003 controller is present. Removing that link removes power to the motor and you won't see any lights.(2) Check that 5 volts is getting to the ULN2003 controller.(3) None of the lights will light when the motor is first turned on as all outputs will be zero.The motor should be rotating if your display is seeing code. Check, with a voltmeter that voltage is appearing on the IN1, IN2, IN3, IN4 input pins. (I have not tried this but you could disconnect say IN1 and apply 5 volts directly, via a 560 ohm .. or 1000 ohm resistor to that pin ... if the controller is okay then one of the lights should light).(4) Is it possible that something is jamming the motor shaft?(5) Check also your wiring ... I tape my arduino connections as they have a ha...

Check that:(1) Check that the link on the ULN2003 controller is present. Removing that link removes power to the motor and you won't see any lights.(2) Check that 5 volts is getting to the ULN2003 controller.(3) None of the lights will light when the motor is first turned on as all outputs will be zero.The motor should be rotating if your display is seeing code. Check, with a voltmeter that voltage is appearing on the IN1, IN2, IN3, IN4 input pins. (I have not tried this but you could disconnect say IN1 and apply 5 volts directly, via a 560 ohm .. or 1000 ohm resistor to that pin ... if the controller is okay then one of the lights should light).(4) Is it possible that something is jamming the motor shaft?(5) Check also your wiring ... I tape my arduino connections as they have a habit of falling out. It only takes one pin.

The sound waves from the transmitter behave like those from a normal radio speaker ... except that we can't hear the sound as it is above our hearing range. Utrasound does penetrate non-metallic objects as it is used in the medical profession but I haven't tried.My scanner detects all solid objects, such as glass metal and wood, but ignores cats and soft furnishings.

Just a thought ... try increasing the motor parameter in the arduino heading from Delay=2; to say Delay=4;I had one motor that refused to start when the delay was time was small.

The short answer is no .... The speed of rotation is affected by all of the following:Within the arduino header: (a) reduce the Delay = 2; to Delay = 1;(b) decrease the "Speed_of_rotation" from 30 down to 1.(c) you could double the motor speed by changing the motor pattern to "full-stepping". I tried this but the 28BJY-48 motor then required a minimum delay of Delay=2 for reliable starting so nothing was gained ... I opted for "half-stepping" as that felt smoother and works with a delay of 1.The serial BAUD speed also affects the speed. Use as high a speed as possible as strings of data take longer at 9600 bauds which slows the hand-shaking.Factors that

Thank you for your comment :) I recently hired a car while overseas and noticed that lights on the wing-mirrors lit up to warn you of nearby vehicles. Perhaps there is already something similar for bikes?

Thanks :)

Thank you for the reference and also for your comment. It's amazing how things get simpler with time !!!

Thank you for your comment :)You could try an array-of-arrays-of-arrays" such as "lamps[pattern][delay][direction]". Such an array would allow any number of different of delays, and directions, to be applied to any pattern. Each lamp delay would require the use of "static" counters.Good luck ...