Error 516 unable to write broken pipe как исправить

Although I use a HC-06 in the below examples the HC-05 in slave mode can also be used.

Using MITs app inventor it is fairly easy to create an app that can turn a LED on and off from an Android device.

This is a fairly simply example of sending commands to the Arduino to turn a LED either on or off. The Android app sends ascii codes to the Arduino via the HC-06 BT module; “ON” for on and “OF” for off.

Load the app, connect to the HC-06 and then use the LED button to turn the LED on and off.

You can also open the serial monitor to see the commands as they are received

The steps involved are:
1. create a circuit that includes a Bluetooth module and a LED
2. create an Arduino sketch that can receive commands from the HC-06 and turn a LED on and off
3. create an Android app that sends commands over Bluetooth

The circuit

The circuit is the same as the one used in Arduino and HC-06 (ZS-040) except the addition of a LED + resistor connected to pin D12. I used a 220 ohm resistor because that is what I had to hand but similar values will be OK.

Based on ohm’s law; using a source of 5V, a green LED with a forward voltage drop of 2.2v and a forward current of 20mA a 150 ohm resistor is recommended. So any value from 180ohm to around 680 ohms will be OK.

Arduino Sketch

The sketch receives data from the Bluetooth module via software serial. It then checks the data for “ON” and “OF” commands. When “ON” is received the LED is turned on and when “OF” is received the LED is turned off.

To ensure that data is received correctly the data is surrounded by start and end markers. This example uses “<» and «>“. I use the function recvWithStartEndMarkers which was posted on the Arduino forum by Robin2. I simply copied the function and did not need to change it.

The recvWithStartEndMarkers() function takes at the data received from the serial connection and copies anything it finds between the start and end markers to the receivedChars variable. When it has found something it sets the newData variable to true.

In the main loop we keep calling the recvWithStartEndMarkers() function until newData has been set. When newData is True we know we have a new command so we call parseData() to deal with it. Inside parseData() we reset newData to false and the process continues.

void loop() 
{
     if (BTserial.available() > 0)     {  recvWithStartEndMarkers(); }
     if (newData) { parseData(); }
}

The full sketch:

// Bluetooth sketch HC-06_02
// Turn a LED on and off from an Android app
// App can be downloaded from www.martyncurrey.com
// 
// Pins
// 2 Software serial - RX
// 3 Software serial - TX
// 12 LED
 
boolean debug = true;
 
#include <SoftwareSerial.h>
SoftwareSerial BTserial(2,3); // RX | TX
// Connect the HC-06 TX to the Arduino RX. 
// Connect the HC-06 RX to the Arduino TX through a voltage divider.
 
// max length of command is 20 chrs
const byte numChars = 20;
char receivedChars[numChars];
boolean newData = false;
 
byte LEDpin = 12;
 
 
void setup() 
{
     pinMode(LEDpin, OUTPUT); 
     Serial.begin(9600);
     Serial.println("<Arduino is ready>");
 
     // The default baud rate for the HC-06s I have is 9600. Other modules may have a different speed. 38400 is common.
     BTserial.begin(9600); 
}
 
void loop() 
{
     if (BTserial.available() > 0)     {  recvWithStartEndMarkers(); }
     if (newData) { parseData(); }
}     
 
 
void parseData()
{  
        newData = false;    
        if (debug) {  Serial.println( receivedChars ); }
        if (receivedChars[0] == 'O'  && receivedChars[1] == 'N' )  { digitalWrite(LEDpin,HIGH);  }
        if (receivedChars[0] == 'O'  && receivedChars[1] == 'F' )  { digitalWrite(LEDpin,LOW);   }       
}
 
 
void recvWithStartEndMarkers() 
{
 
     // function recvWithStartEndMarkers by Robin2 of the Arduino forums
     // See  http://forum.arduino.cc/index.php?topic=288234.0
 
     static boolean recvInProgress = false;
     static byte ndx = 0;
     char startMarker = '<';
     char endMarker = '>';
     char rc;
 
     if (BTserial.available() > 0) 
     {
          rc = BTserial.read();
          if (recvInProgress == true) 
          {
               if (rc != endMarker) 
               {
                    receivedChars[ndx] = rc;
                    ndx++;
                    if (ndx >= numChars) { ndx = numChars - 1; }
               }
               else 
               {
                     receivedChars[ndx] = ''; // terminate the string
                     recvInProgress = false;
                     ndx = 0;
                     newData = true;
               }
          }
 
          else if (rc == startMarker) { recvInProgress = true; }
     }
}

Android App

I created the Android app in MITs app inventor. This was fairly easy once I had figured out how to use Bluetooth.

The app is very basic, it simply sends commands. There are no checks to see if the Arduino has actually received the commands or not. The screen is also very simple; it has a button for connecting to Bluetooth and a on/off button to control the LED. The app uses a ListPicker to store the available Bluetooth devices which is not displayed on screen. It is initiated from the connect button.

The app has 4 blocks and a list:

Block 1

This handles the connect button. When the button is clicked the block/function first checks to see if Bluetooth is enabled and then checks to see if there is already a Bluetooth connection. If Bluetooth is not turned on an error message is displayed. If there is already an active connection the user is asked if they would like to close it. The user reply is handled in Block3, Notifier1.AfterChoosing

If Bluetooth is on and there isn’t a current connection the paired Bluetooth devices are copied to the Bluetooth pairedDevices List. If the list has at least 1 item the contents of the list are copied to the ListPicker. The ListPicker is then activated to allow the user to select a Bluetooth device. I use the pairedDevices list so that I can count the number paired devices. I could not find a way of doing this when using just a ListPicker. If the list is empty an error message is displayed saying there are no paired devices.

Block 2

Block 2, BT_LP.AfterPicking handles the List Picker after the user has selected one of the paired Bluetooth devices. It takes the selected item and tries to connect. If successful the text on the Bluetooth button is changed to “Connected”. If a connection cannot be established an error message is displayed.

Once a connection is established the app waits for the LED button to be pressed.

Block 3

Block 3 handles a Notifier dialogue that asks the user if they wish to close the connection

Block 4

Block 4, LED_BUTTON_btn.Click, handles the LED button. By checking the button text we can determine what command to send. If the text says “ON” then the LED is on and we need to turn it off so we send an “OF” command. If the text says “OFF”, the LED is off so we send an “ON” command to turn it on. The actual commands are “<ON>” and “<OF>”. The button text and background colour are updated to reflect the new LED status.

An error message is displayed if the LED button is clicked and there is no active connection.

Download

Download the zip file containing the Arduino sketch, the ardiunoBTcontrol app and the appinventor aia file.

 
In part 2 we add 2-way communication and the facility to control the LED from the Arduino as well as the app.

Related:
Add an auto-connect function to an App Inventor app. http://www.martyncurrey.com/android-mit-app-inventor-auto-connect-to-bluetooth/

Note that a push can still freeze (even with postBuffer increased) when its pack files are corrupted (ie pack-objects fails)

That will be fixed in git 2.9 (June 2016). And better managed with Git 2.25 (Q1 2020)

See commit c4b2751, commit df85757, commit 3e8b06d, commit c792d7b, commit 739cf49 (19 Apr 2016) by Jeff King (peff).
^{(Merged by Junio C Hamano — gitster — in commit d689301, 29 Apr 2016)}

«git push» from a corrupt repository that attempts to push a large number of refs deadlocked; the thread to relay rejection notices for these ref updates blocked on writing them to the main thread, after the main thread at the receiving end notices that the push failed and decides not to read these notices and return a failure.

Commit 739cf49 has all the details.

send-pack: close demux pipe before finishing async process

This fixes a deadlock on the client side when pushing a large number of refs from a corrupted repo.

With Git 2.25 (Q1 2020), Error handling after «git push» finishes sending the packdata and waits for the response to the remote side has been improved.

See commit ad7a403 (13 Nov 2019) by Jeff King (peff).
^{(Merged by Junio C Hamano — gitster — in commit 3ae8def, 01 Dec 2019)}

send-pack: check remote ref status on pack-objects failure

^{Helped-by: SZEDER Gábor
Signed-off-by: Jeff King}

When we’re pushing a pack and our local pack-objects fails, we enter an error code path that does a few things:

1. Set the status of every ref to REF_STATUS_NONE
2. Call receive_unpack_status() to try to get an error report from the other side
3. Return an error to the caller

If pack-objects failed because the connection to the server dropped, there’s not much more we can do than report the hangup. And indeed, step 2 will try to read a packet from the other side, which will die() in the packet-reading code with «the remote end hung up unexpectedly«.

But if the connection didn’t die, then the most common issue is that the remote index-pack or unpack-objects complained about our pack (we could also have a local pack-objects error, but this ends up being the same; we’d send an incomplete pack and the remote side would complain).

In that case we do report the error from the other side (because of step 2), but we fail to say anything further about the refs.

The issue is two-fold:

• in step 1, the «NONE» status is not «we saw an error, so we have no status».
  It generally means «this ref did not match our refspecs, so we didn’t try to push it». So when we print out the push status table, we won’t mention any refs at all!
  But even if we had a status enum for «pack-objects error», we wouldn’t want to blindly set it for every ref. For example, in a non-atomic push we might have rejected some refs already on the client side (e.g., REF_STATUS_REJECT_NODELETE) and we’d want to report that.
• in step 2, we read just the unpack status.
  But receive-pack will also tell us about each ref (usually that it rejected them because of the unpacker error).

So a much better strategy is to leave the ref status fields as they are (usually EXPECTING_REPORT) and then actually receive (and print) the full per-ref status.

This case is actually covered in the test suite, as t5504.8, which writes a pack that will be rejected by the remote unpack-objects.
But it’s racy. Because our pack is small, most of the time pack-objects manages to write the whole thing before the remote rejects it, and so it returns success and we print out the errors from the remote.
But very occasionally (or when run under --stress), it goes slow enough to see a failure in writing, and git push reports nothing for the refs.

With this patch, the test should behave consistently.

There shouldn’t be any downside to this approach.

• If we really did see the connection drop, we’d already die in receive_unpack_status(), and we’ll continue to do so.
• If the connection drops after we get the unpack status but before we see any ref status, we’ll still print the remote unpacker error, but will now say «remote end hung up» instead of returning the error up the call-stack.
  But as discussed, we weren’t showing anything more useful than that with the current code. And anyway, that case is quite unlikely (the connection dropping at that point would have to be unrelated to the pack-objects error, because of the ordering of events).

In the future we might want to handle packet-read errors ourself instead of dying, which would print a full ref status table even for hangups.
But in the meantime, this patch should be a strict improvement.

Note: Similar question has been posted years ago. Yet the debugging procudure provided by the long answer didn’t help. And the last posted, supposedly the solution for it is very unintuitive. So here I am, post the question again.

My printer is connected through socket://ip.of.printer:9100. The model of printer is LaserJet P4015n. My computer is running Arch Linux. The version of cup related modules are:

cups-2.0.4-1-x86_64
cups-filters-1.0.71-1
cups-pk-helper-0.2.5-1
libcups-2.0.4-1
python-pycups-1.9.73-1

The printing system of my computer used to be working fine. Yet today when I try to print a document, the printer do not respond. Downgrading all cup related packages to earliest version I have on my computer doesn’t help. Neither does reinstalling the printer driver.

When debugging, # nc -vz ip.of.printer 9100 returning normal connection,

...[ip.of.printer] 9100 (hp-pdl-datastr) open

Checking /var/log/cups/error_log, only related message was

E [22/Aug/2015:01:15:33 +0800] [Job 35] Unable to write print data: Broken pipe

And printer related result of tcpdump is posted as below(localhost name is Saturn, I traced Saturn.57142 due to it’s the connection with HP LaserJet P4015):

00:42:12.748387 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetRequest(28)  25.3.2.1.3.1
00:42:12.753755 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(45)  25.3.2.1.3.1="HP LaserJet P4015"
00:42:12.753904 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetNextRequest(27)  43.12.1.1.4
00:42:12.758850 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(34)  43.12.1.1.4.1.1="black"
00:42:12.758900 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetNextRequest(29)  43.12.1.1.4.1.1
00:42:12.763940 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(30)  43.12.1.1.5.1.1=8
00:42:12.764116 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetRequest(28)  25.3.5.1.2.1
00:42:12.771071 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(29)  25.3.5.1.2.1=00
00:42:12.771123 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetRequest(29)  43.10.2.1.4.1.1
00:42:12.775906 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(32)  43.10.2.1.4.1.1=51928

00:42:12.838656 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetNextRequest(27)  43.11.1.1.9
00:42:12.843572 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(31)  43.11.1.1.9.1.1=9120
00:42:12.843675 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetNextRequest(29)  43.11.1.1.9.1.1
00:42:12.848515 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(32)  43.11.1.1.9.1.2=173092
00:42:12.848630 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetNextRequest(29)  43.11.1.1.9.1.2
00:42:12.854099 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(30)  43.12.1.1.2.1.1=1
00:42:12.854138 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetRequest(28)  25.3.5.1.2.1
00:42:12.861080 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(29)  25.3.5.1.2.1=00


00:42:13.261306 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetNextRequest(27)  43.11.1.1.9
00:42:13.266306 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(31)  43.11.1.1.9.1.1=9120
00:42:13.266332 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetNextRequest(29)  43.11.1.1.9.1.1
00:42:13.271211 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(32)  43.11.1.1.9.1.2=173092
00:42:13.271254 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetNextRequest(29)  43.11.1.1.9.1.2
00:42:13.276577 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(30)  43.12.1.1.2.1.1=1
00:42:13.276675 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetRequest(28)  25.3.5.1.2.1
00:42:13.283540 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(29)  25.3.5.1.2.1=00
00:42:13.283623 IP Saturn.57142 > NPI7B3356.DynIP.ntu.edu.sg.snmp:  GetRequest(29)  43.10.2.1.4.1.1
00:42:13.288444 IP NPI7B3356.DynIP.ntu.edu.sg.snmp > Saturn.57142:  GetResponse(32)  43.10.2.1.4.1.1=51928

Any idea on how to solve the issue?