Following deviation is too large ошибка

Ошибка HTTP 413 Request Entity Too Large появляется, когда пользователь пытается загрузить на сервер слишком большой файл. Размер определяется относительно лимита, который установлен в конфигурации. Изменить его может только администратор сервера. 

Что делать, если вы пользователь

Если вы видите ошибку 413, когда пытаетесь загрузить файл на чужом сайте, то вам нужно уменьшить размер передаваемых данных. Вот несколько ситуаций.

  • Если вы пытались загрузить одновременно несколько файлов (форма позволяет так делать), попробуйте загружать их по одному.
  • Если не загружается изображение, уменьшите его размер перед загрузкой на сервер. Можно сделать это с помощью онлайн-сервисов — например, Tiny PNG.
  • Если не загружается видео, попробуйте сохранить его в другом формате и уменьшить размер. Можно сделать это с помощью онлайн-сервисов — я использую Video Converter.
  • Если не загружается PDF-документ, уменьшите его размер. Можно сделать это с помощью онлайн-сервисов — я обычно использую PDF.io.

Универсальный вариант — архивация файла со сжатием. Ошибка сервера 413 появляется только в том случае, если вы пытаетесь одновременно загрузить слишком большой объем данных. Поэтому и выход во всех ситуациях один — уменьшить размер файлов.

Ошибка 413

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться

Исправление ошибки сервера 413 владельцем сайта

Если вы владелец сайта, который при загрузке файлов выдает ошибку 413, то необходимо изменить конфигурацию сервера. Порядок действий зависит от используемых технологий.

Чтобы понять, что стало причиной ошибки, нужно посмотреть логи. Это поможет сэкономить время. Вот подробная инструкция, которая рассказывает, как посмотреть логи в панели управления Timeweb. В зависимости от того, какая информация будет в логах, вы поймете, как исправлять ошибку 413.

Увеличение разрешенного размера для загрузки файлов на Nginx и Apache

На Nginx максимально допустимый размер файла задан в параметре client_max_body_size. По умолчанию он равен 1 МБ. Если запрос превышает установленное значение, пользователь видит ошибку 413 Request Entity Too Large. 

Параметр client_max_body_size находится в файле nginx.conf. Для его изменения нужен текстовый редактор — например, vi.

Подключитесь к серверу через SSH и выполните в консоли следующую команду:

Во встроенном редакторе vi откроется файл nginx.conf. В разделе http добавьте или измените следующую строку:

client_max_body_size 20M;

Сохраните и закройте файл. Затем проверьте конфигурацию файла:

Перезагрузите сервер следующей командой:

После перезагрузки будет действовать новая конфигурация с увеличенным лимитом на размер загружаемого файла.

На Apache опция, устанавливающая максимально допустимый размер загружаемого файла, называется LimitRequestBody. По умолчанию лимит не установлен (равен 0). 

На CentOS главный конфиг располагается по адресу /etc/httpd/conf/httpd.conf. На Debian/Ubuntu — по адресу /etc/apache2/apache2.conf

Значение задается в байтах:

LimitRequestBody 33554432

Эта запись выставляет максимально допустимый размер 32 МБ.

Изменить конфиги можно также через панель управления. Я пользуюсь ISPmanager, поэтому покажу на ее примере.

  1. Раскройте раздел «Домены» и перейдите на вкладку «WWW-домены».
  2. Выберите домен, на котором появляется ошибка, и нажмите на кнопку «Конфиг».

Apache и Nginx конфиги

Появится вкладка с конфигами Apache и Nginx. Вы можете редактировать их вручную, устанавливая лимит на размер загружаемого файла.

Исправление ошибки на WordPress

На WordPress ошибку можно исправить двумя способами.

Способ первый — изменение разрешенного размера в файле functions.php. Этот файл отвечает за добавление функций и возможностей — например, меню навигации.

  1. Откройте файловый менеджер.
  2. Перейдите в папку public.html.
  3. Откройте директорию wp-content/themes.
  4. Выберите тему, которая используется на сайте с WordPress.
  5. Скачайте файл functions.php и откройте его через любой текстовый редактор.

В панели управления на Timeweb можно также воспользоваться встроенным редактором или IDE — путь будет такой же, как указан выше: public.html/wp-content/themes/ваша тема/functions.php

В конце файла functions.php добавьте следующий код: 

@ini_set( 'upload_max_size' , '256M' );

@ini_set( 'post_max_size', '256M');

@ini_set( 'max_execution_time', '300' );

Сохраните изменения и загрузите модифицированный файл обратно на сервер. Проверьте, появляется ли ошибка 413. 

Редактирование файла functions.php

Второй способ — изменение файла .htaccess. Это элемент конфигурации, который способен переопределять конфигурацию сервера в плане авторизации, кэширования и даже оптимизации. Найти его можно через файловый менеджер в папке public.html.

Скачайте файл на компьютер, на всякий случай сделайте резервную копию. Затем откройте .htaccess в текстовом редакторе и после строчки #END WORDPRESS вставьте следующий код:

php_value upload_max_filesize 999M

php_value post_max_size 999M

php_value max_execution_time 1600

php_value max_input_time 1600

Сохраните файл и загрузите его обратно на сервер с заменой исходного файла. То же самое можно сделать через встроенный редактор или IDE в панели управления Timeweb.

Исправление ошибки при использовании PHP-скрипта

Если файлы загружаются с помощью PHP-скрипта, то для исправления ошибки 413 нужно отредактировать файл php.ini. В нем нас интересуют три директивы.:

  • upload_max_filesize — в ней указан максимально допустимый размер загружаемого файла (значение в мегабайтах);
  • post_max_size — максимально допустимый размер данных, отправляемых методом POST (значение в мегабайтах);
  • max_execution_time — максимально допустимое время выполнения скрипта (значение в секундах).

Например, если я хочу, чтобы пользователи могли загружать файлы размером до 20 МБ, то я делаю так:

max_execution_time = 90

post_max_size = 20M

upload_max_filesize = 20M

Если все значения указаны верно, то файлы с допустимым размером будут загружаться на сервер без ошибок.

То же самое можно сделать через панель управления. Например, в ISPmanager порядок будет такой:

  1. Авторизуйтесь с root-правами.
  2. В левом меню раскройте раздел «Настройки web-сервера» и перейдите на вкладку «PHP».
  3. Выберите используемую версию и нажмите на кнопку «Изменить».

Изменение конфигурации PHP

На экране появится список параметров. Они отсортированы по алфавиту. Установите необходимые значения для параметров max_execution_time, post_max_size и upload_max_filesize. Изменения применяются автоматически.

VDS Timeweb арендовать

I have been getting this 413 response when trying to upload an ~20MB zip file with a home grown (but not by me) document library resource developed in PHP running on an Apache server with a MySQL database connected. Normally the max file size is limited to 5.2MB in a local PHP variable. So the first thing I did was to increase this value and try to upload the file. That’s the first time I encountered this error.

I tried everything mentioned here: Request Entity Too Large

And even changed the mod_security config settings mentioned in the bottom of that post. Even with all the limits I found raised far above what I should need — up to ~120MB, I still get this error.

MarcoS's user avatar

MarcoS

17k23 gold badges93 silver badges168 bronze badges

asked Oct 22, 2014 at 13:02

logofwood's user avatar

1

This worked fine for me maybe this helps you to upload larger files:
Change these values in php.ini:

upload_max_filesize 3000M
post_max_size 3000M
max_execution_time 3600
max_input_time 3600

answered Oct 22, 2014 at 13:11

Kevinkuijer's user avatar

KevinkuijerKevinkuijer

1301 silver badge13 bronze badges

1

So after posting this, I found another mod_security limit that needed to be raised appropriately.

SecRequestBodyLimit was too low (131072).

This is probably a corner case, but hope it helps someone else.

answered Oct 22, 2014 at 13:47

logofwood's user avatar

logofwoodlogofwood

311 silver badge3 bronze badges

1

None of the listed fixed my problem. They were all set much higher than needed. I was posting 100k-500k textarea fields. What did fix it for me was adding the following to the <form> tag.

enctype="multipart/form-data"

answered Jan 27, 2015 at 18:16

Krojack's user avatar

Иногда при загрузке больших файлов на какой-либо веб-сайт может возникнуть ошибка, которую возвращает веб-сервер Nginx — 413 Request Entity Too Large. Данная ошибка появляется, при попытке загрузить на сервер слишком большой файл чем это разрешено на сервере.

В данной небольшой статье будет рассмотрено описание ошибки 413 Request Entity Too Large а также методы её исправления на стороне веб-сервера Nginx.

Ошибка 413 Request Entity Too Large дословно расшифровывается как объект запроса слишком велик или простыми словами объем передаваемых данных слишком большой. Данная ошибка возвращается в случае, если сервер не может обработать запрос по причине слишком большого размера тела запроса (или большого файла). Снимок экрана с ошибкой изображен ниже:

wP47iP96W9YvAAAAABJRU5ErkJggg==

По умолчанию в Nginx установлен лимит на размер тела запроса который равен 1 МБ. Если запрос превышает установленное значение, вы увидите ошибку 413 Request Entity Too Large.

Как исправить ошибку 413 Request Entity Too Large

Для того чтобы исправить данную ошибку необходимо увеличить допустимый лимит. Чтобы увеличить размер тела запроса и соответственно, загружаемых файлов, необходимо использовать параметр client_max_body_size. Данную опцию можно использовать в директивах http, server или location в конфигурационном файле /etc/nginx/nginx.conf или в конфигурационном файле веб-сайта.

Для этого необходимо открыть конфигурационный файл nginx.conf при помощи любого текстового редактора (например nano):

sudo nano /etc/nginx/nginx.conf

u5OMyOApCqZjMZNjHz4K0trEFvM5Pj+P8DzCrRn+soy7wAAAAASUVORK5CYII=

Далее впишите такую строчку в секцию http:

client_max_body_size 100M

Здесь 100 — это максимальный размер файла в мегабайтах который можно загрузить на веб-сайт, в данном случае — 100 мегабайт. Если в распоряжении имеется несколько веб-сайтов (серверные блоки в терминологии Nginx, они же виртуальные хосты в понимании другого веб-сервера — Apache) и необходимо чтобы ограничение на загрузку действовало на все сайты сразу, то строку client_max_body_size необходимо вписать в раздел блока http. Как было показано выше.

Если ограничение на загрузку необходимо выставить только для конкретного сайта, то строку client_max_body_size необходимо добавить в блок server конфигурационного файла сайта, который по умолчанию находиться в /etc/nginx/sites-available/имя_файла_с_конфигурацией:

8H6OBHbwZnuAcAAAAASUVORK5CYII=

Если ограничение на загрузку необходимо выставить только для конкретного раздела на сайте, строку client_max_body_size необходимо вписать в директиву location конфигурационного файла сайта, который по умолчанию находиться в /etc/nginx/sites-available/имя_файла_с_конфигурацией:

KxgCLvBCQMwAAAAASUVORK5CYII=

После внесения изменений в конфигурационные файлы необходимо сохранить изменения, закрыть текстовый редактор и проверить синтаксис конфигурационных файлов на наличие ошибок при помощи команды:

sudo nginx -t

j8OjMTx6bbbpAAAAABJRU5ErkJggg==

Если в выводе команды будут отображены следующие строки:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Это означает что ошибок нет. В противном случае будет выведено описание ошибки, имя файла в котором найдена ошибка и номер строки. После внесения любых изменений в конфигурационные файлы Nginx их необходимо перезапустить при помощи команды:

sudo systemctl reload nginx

Выводы

В данной короткой статье была рассмотрена ошибка в Nginx под названием 413 Request Entity Too Large которая возникает при загрузке больших файлов на веб-сайт. Помимо описания самой ошибки также было описаны шаги по устранению ошибки путем редактирования конфигурационных файлов Nginx.

Creative Commons License

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Об авторе

Бывший системный администратор и DevOps инженер. Ныне работаю по направлению DevSecOps. Использую Linux более 5 лет. Помимо Linux интересую языком программирования Python, базами данных и языком SQL а также информационной безопасностью.

WordPress errors come in all shapes and sizes. In most cases they’re easy to decipher; such is the accessibility of WordPress’ error reporting. Even so, when the “413 Request Entity Too Large” error pops up, it can leave you scratching your head.

Without realizing it, you already have everything you need to understand and diagnose the error within its name. The good news is you won’t need more than a standard Secure File Transfer Protocol (SFTP) client and administrator access to your server.

In this post, we’ll take a look at how to solve the “413 Request Entity Too Large” error. We’ll also give you a quick list of steps to take before you begin to solve the error, to make the process super straightforward.

Check out our video guide to fixing the “413 Request Entity Too Large” Error

What the “413 Request Entity Too Large” Error Is (And Why It Exists)

We noted that there’s a clue in the error name as to what the solution and problem are. Before you go sleuthing yourself, though, we’ll spoil the surprise: it’s in the adjective “large.”

In a nutshell, the “413 Request Entity Too Large” error is a size issue. It happens when a client makes a request that’s too large for the end server to process. Depending on the nature of the error, the server could close the connection altogether to prevent further requests being made.

Let’s break the error down into its parts:

  • “413”: This is one of the 4xx error codes, which mean there’s a problem between the server and browser.
  • “Request Entity”: The “entity” in this case is the information payload being requested by the client from the server.
  • “Too Large”: This is straightforward: the entity is bigger than the server is willing or able to serve.

In fact, this error has changed its name from what it originally was to be more specific and offer more clarity. It’s now known as the “413 Payload Too Large” error, although in practice, you’ll see the older name a lot more.

As for why the error occurs, the simple explanation is that the server is set up to deny explicit uploads that are too large. Think of times when you upload a file where there’s a maximum file size limit:

The TinyPNG home page with the max upload of 5mb highlighted.

The TinyPNG home page.

In most cases, there will be some validation in place to stop the error… if you’re seeing the “413 Request Entity Too Large” error, those validation efforts may not be as watertight as you think.

What You’ll Need to Resolve the “413 Request Entity Too Large” Error

Fixing this error is all about raising the maximum file size for the server in question. Once that’s out of the way, you shouldn’t see the error anymore.

As such, to fix the “413 Request Entity Too Large” error, you’ll need the following:

  • Administrator access to your server.
  • A suitable SFTP client (we’ve covered many of these in the past).
  • The know-how to use SFTP — there’s a good guide to the basics on WordPress.org, and you won’t need more than that.
  • A text editor, though there’s no need for anything too complex.
  • A clean and current backup in case the worst happens.

As an aside, we mention SFTP throughout this article as opposed to FTP. In short, the former is more secure than the latter (hence the name). That said, while there are other differences you should investigate, the functionality remains the same for the vast majority of uses.

Also, it’s worth noting that the MyKinsta dashboard has plenty of functionality on hand to help you get onto your server. For example, each site displays SFTP connection information that’s easy to understand:

The SFTP panel in the MyKinsta dashboard.

The SFTP panel in the MyKinsta dashboard.

This can help you get into your site without fuss. In some cases, you may be able to import the credentials straight to your chosen SFTP client.

3 “Pre-Steps” You Can Take Before Rectifying the “413 Request Entity Too Large” Error

Before you crack open your toolbox, there are some steps you can take to help resolve the “413 Request Entity Too Large” error. Here are two — and each one may give you a welcome workaround to the error.

1. Try to Upload a Large File to Your Server Through SFTP

Because the issue is related to the file sizes hitting your server, it’s a good idea to circumvent the frontend interface and upload a large file to the server yourself. The best way to do this is through SFTP.

This is because protocols such as SFTP are almost as “close to the bone” as you can get with regards to the way you access your server. Also, you can simultaneously rule out any issues with the frontend that may be causing the error.

To do this, log into your site through SFTP and find the wp-content folder. In here will be the uploads folder.

The uploads folder seen from an SFTP client.

The uploads folder seen from an SFTP client.

Next, upload your file to this folder on the server and see what the outcome is. If the upload is successful, we suggest sending an email to the site’s developer, as they may want to investigate the issue further on the frontend.

2. Check for Server Permissions Errors

Of course, permissions errors will stop any server request from running. As such, you should check whether the user has sufficient permissions to upload files of any size. Once this is sorted, the error should disappear.

The first step is to determine whether this is an issue with a single user (in which case they may be restricted for a reason). If the “413 Request Entity Too Large” error is happening for multiple users, you can be more sure of something that needs your input.

We’d suggest two “pre-fixes” here:

  • Double-check your WordPress file permissions, just in case there’s an issue.
  • Remove and re-create your SFTP user (a general investigation is a great idea).

While they may not solve the error in the first instance, you’ll at least know that your file and user structure is as it should be.

How to Solve the “413 Request Entity Too Large Error” for Your WordPress Website (3 Ways)

Once you’ve gone through the pre-steps, you’re ready to tackle the error head-on.

The following three methods are listed from easiest to toughest, with the understanding that that the path of least resistance is the best one to take.

1. Edit Your WordPress functions.php File

First off, you can work with your functions.php file to help bump up the file upload size for your site. To do this, first log into your site through SFTP using the credentials found within your hosting control panel.

When you’re in, you’ll want to look for the file itself. The functions.php file should be in the root of your server. In many cases, this root is called www or public_html, or it could be the abbreviated name of your site.

Once you’ve found it, you can open it in your text editor of choice. If you don’t see the file, you can create it using your text editor.

Once you have a file open, enter the following:

@ini_set( '_max_size' , '64M' );
@ini_set( 'post_max_size', '64M');
@ini_set( 'max_execution_time', '300' );

In short, this increases the maximum file size of posts and uploads while boosting the time the server will spend trying to process the request. The numbers here could be anything you wish, but they should be large enough to make the error disappear. In practice, 64 MB is enough for all but the most heavy-duty of tasks.

The functions.php file.

The functions.php file.

When you’re ready, save your file and upload it to the server again. Then, check whether the “413 Request Entity Too Large” error still exists. If it does, head onto the next method.

2. Modify Your WordPress .htaccess File

Much like your functions.php file, your .htaccess file sits on your server. The difference here is that .htaccess is a configuration file for Apache servers. If you’re a Kinsta customer, you’ll know we run Nginx servers, so you won’t see this file in your setup.

Still, for those with an Apache server, this is the approach you’ll need. Much like with the guidance for functions.php, first log into your server through SFTP, then look in your root folder as before.

The .htaccess file should be within this directory, but if it’s missing, we suggest you get in touch with your host to determine where it is, and whether your server runs on Nginx instead.

Once you’ve found it, open it up again. You’ll see some tags, and the most important here is # END WordPress. You’ll want to paste the following after this line:

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300

In short, this does almost the same thing as the code you’d add to the functions.php file, but it’s akin to giving the server direct instructions.

The .htaccess file.

The .htaccess file.

When you’ve finished, save your changes, upload the file, and check your site again. If you’re still having trouble, we’d again suggest contacting your host, as they will need to verify some aspects of your setup that lie beyond the scope of this article.

3. Change Your Nginx Server Configuration

Our final method is specific to Nginx servers — those used at Kinsta. The purpose is the same as when working with the .htaccess file, in that you’re talking to the server, rather than going through WordPress.

We mentioned that for Apache servers you’ll use .htaccess. For Nginx servers, though, you’ll want to find the nginx.conf file. Rather than walk you through every step in the chain, we’ve gone over the full details in our post on changing the WordPress maximum upload size.

Remember that you’ll need to also alter the php.ini file based on the changes you make to nginx.conf. We’ve covered that in the aforementioned blog post too, so take a look there for the exact steps.

Summary

Despite WordPress being a rock-solid platform, you’ll see a lot of different WordPress errors over time. The “413 Request Entity Too Large” error is related to your server, though — not WordPress. As such, there’s a different approach to solving this error than other platform-specific issues.

If you have SFTP skills, there’s no reason you can’t fix this error quickly. It relates to the upload size specified in your server configuration files, so digging into your .htaccess or nginx.config files will be necessary. It’s a breeze to crack open your text editor and make the changes to these files, and if you’re a Kinsta customer, we’re on hand to support you through the process.


Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:

  • Easy setup and management in the MyKinsta dashboard
  • 24/7 expert support
  • The best Google Cloud Platform hardware and network, powered by Kubernetes for maximum scalability
  • An enterprise-level Cloudflare integration for speed and security
  • Global audience reach with up to 35 data centers and 275 PoPs worldwide

Test it yourself with $20 off your first month of Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.

WordPress errors come in all shapes and sizes. In most cases they’re easy to decipher; such is the accessibility of WordPress’ error reporting. Even so, when the “413 Request Entity Too Large” error pops up, it can leave you scratching your head.

Without realizing it, you already have everything you need to understand and diagnose the error within its name. The good news is you won’t need more than a standard Secure File Transfer Protocol (SFTP) client and administrator access to your server.

In this post, we’ll take a look at how to solve the “413 Request Entity Too Large” error. We’ll also give you a quick list of steps to take before you begin to solve the error, to make the process super straightforward.

Check out our video guide to fixing the “413 Request Entity Too Large” Error

What the “413 Request Entity Too Large” Error Is (And Why It Exists)

We noted that there’s a clue in the error name as to what the solution and problem are. Before you go sleuthing yourself, though, we’ll spoil the surprise: it’s in the adjective “large.”

In a nutshell, the “413 Request Entity Too Large” error is a size issue. It happens when a client makes a request that’s too large for the end server to process. Depending on the nature of the error, the server could close the connection altogether to prevent further requests being made.

Let’s break the error down into its parts:

  • “413”: This is one of the 4xx error codes, which mean there’s a problem between the server and browser.
  • “Request Entity”: The “entity” in this case is the information payload being requested by the client from the server.
  • “Too Large”: This is straightforward: the entity is bigger than the server is willing or able to serve.

In fact, this error has changed its name from what it originally was to be more specific and offer more clarity. It’s now known as the “413 Payload Too Large” error, although in practice, you’ll see the older name a lot more.

As for why the error occurs, the simple explanation is that the server is set up to deny explicit uploads that are too large. Think of times when you upload a file where there’s a maximum file size limit:

The TinyPNG home page with the max upload of 5mb highlighted.

The TinyPNG home page.

In most cases, there will be some validation in place to stop the error… if you’re seeing the “413 Request Entity Too Large” error, those validation efforts may not be as watertight as you think.

What You’ll Need to Resolve the “413 Request Entity Too Large” Error

Fixing this error is all about raising the maximum file size for the server in question. Once that’s out of the way, you shouldn’t see the error anymore.

As such, to fix the “413 Request Entity Too Large” error, you’ll need the following:

  • Administrator access to your server.
  • A suitable SFTP client (we’ve covered many of these in the past).
  • The know-how to use SFTP — there’s a good guide to the basics on WordPress.org, and you won’t need more than that.
  • A text editor, though there’s no need for anything too complex.
  • A clean and current backup in case the worst happens.

As an aside, we mention SFTP throughout this article as opposed to FTP. In short, the former is more secure than the latter (hence the name). That said, while there are other differences you should investigate, the functionality remains the same for the vast majority of uses.

Also, it’s worth noting that the MyKinsta dashboard has plenty of functionality on hand to help you get onto your server. For example, each site displays SFTP connection information that’s easy to understand:

The SFTP panel in the MyKinsta dashboard.

The SFTP panel in the MyKinsta dashboard.

This can help you get into your site without fuss. In some cases, you may be able to import the credentials straight to your chosen SFTP client.

3 “Pre-Steps” You Can Take Before Rectifying the “413 Request Entity Too Large” Error

Before you crack open your toolbox, there are some steps you can take to help resolve the “413 Request Entity Too Large” error. Here are two — and each one may give you a welcome workaround to the error.

1. Try to Upload a Large File to Your Server Through SFTP

Because the issue is related to the file sizes hitting your server, it’s a good idea to circumvent the frontend interface and upload a large file to the server yourself. The best way to do this is through SFTP.

This is because protocols such as SFTP are almost as “close to the bone” as you can get with regards to the way you access your server. Also, you can simultaneously rule out any issues with the frontend that may be causing the error.

To do this, log into your site through SFTP and find the wp-content folder. In here will be the uploads folder.

The uploads folder seen from an SFTP client.

The uploads folder seen from an SFTP client.

Next, upload your file to this folder on the server and see what the outcome is. If the upload is successful, we suggest sending an email to the site’s developer, as they may want to investigate the issue further on the frontend.

2. Check for Server Permissions Errors

Of course, permissions errors will stop any server request from running. As such, you should check whether the user has sufficient permissions to upload files of any size. Once this is sorted, the error should disappear.

The first step is to determine whether this is an issue with a single user (in which case they may be restricted for a reason). If the “413 Request Entity Too Large” error is happening for multiple users, you can be more sure of something that needs your input.

We’d suggest two “pre-fixes” here:

  • Double-check your WordPress file permissions, just in case there’s an issue.
  • Remove and re-create your SFTP user (a general investigation is a great idea).

While they may not solve the error in the first instance, you’ll at least know that your file and user structure is as it should be.

How to Solve the “413 Request Entity Too Large Error” for Your WordPress Website (3 Ways)

Once you’ve gone through the pre-steps, you’re ready to tackle the error head-on.

The following three methods are listed from easiest to toughest, with the understanding that that the path of least resistance is the best one to take.

1. Edit Your WordPress functions.php File

First off, you can work with your functions.php file to help bump up the file upload size for your site. To do this, first log into your site through SFTP using the credentials found within your hosting control panel.

When you’re in, you’ll want to look for the file itself. The functions.php file should be in the root of your server. In many cases, this root is called www or public_html, or it could be the abbreviated name of your site.

Once you’ve found it, you can open it in your text editor of choice. If you don’t see the file, you can create it using your text editor.

Once you have a file open, enter the following:

@ini_set( '_max_size' , '64M' );
@ini_set( 'post_max_size', '64M');
@ini_set( 'max_execution_time', '300' );

In short, this increases the maximum file size of posts and uploads while boosting the time the server will spend trying to process the request. The numbers here could be anything you wish, but they should be large enough to make the error disappear. In practice, 64 MB is enough for all but the most heavy-duty of tasks.

The functions.php file.

The functions.php file.

When you’re ready, save your file and upload it to the server again. Then, check whether the “413 Request Entity Too Large” error still exists. If it does, head onto the next method.

2. Modify Your WordPress .htaccess File

Much like your functions.php file, your .htaccess file sits on your server. The difference here is that .htaccess is a configuration file for Apache servers. If you’re a Kinsta customer, you’ll know we run Nginx servers, so you won’t see this file in your setup.

Still, for those with an Apache server, this is the approach you’ll need. Much like with the guidance for functions.php, first log into your server through SFTP, then look in your root folder as before.

The .htaccess file should be within this directory, but if it’s missing, we suggest you get in touch with your host to determine where it is, and whether your server runs on Nginx instead.

Once you’ve found it, open it up again. You’ll see some tags, and the most important here is # END WordPress. You’ll want to paste the following after this line:

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300

In short, this does almost the same thing as the code you’d add to the functions.php file, but it’s akin to giving the server direct instructions.

The .htaccess file.

The .htaccess file.

When you’ve finished, save your changes, upload the file, and check your site again. If you’re still having trouble, we’d again suggest contacting your host, as they will need to verify some aspects of your setup that lie beyond the scope of this article.

3. Change Your Nginx Server Configuration

Our final method is specific to Nginx servers — those used at Kinsta. The purpose is the same as when working with the .htaccess file, in that you’re talking to the server, rather than going through WordPress.

We mentioned that for Apache servers you’ll use .htaccess. For Nginx servers, though, you’ll want to find the nginx.conf file. Rather than walk you through every step in the chain, we’ve gone over the full details in our post on changing the WordPress maximum upload size.

Remember that you’ll need to also alter the php.ini file based on the changes you make to nginx.conf. We’ve covered that in the aforementioned blog post too, so take a look there for the exact steps.

Summary

Despite WordPress being a rock-solid platform, you’ll see a lot of different WordPress errors over time. The “413 Request Entity Too Large” error is related to your server, though — not WordPress. As such, there’s a different approach to solving this error than other platform-specific issues.

If you have SFTP skills, there’s no reason you can’t fix this error quickly. It relates to the upload size specified in your server configuration files, so digging into your .htaccess or nginx.config files will be necessary. It’s a breeze to crack open your text editor and make the changes to these files, and if you’re a Kinsta customer, we’re on hand to support you through the process.


Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:

  • Easy setup and management in the MyKinsta dashboard
  • 24/7 expert support
  • The best Google Cloud Platform hardware and network, powered by Kubernetes for maximum scalability
  • An enterprise-level Cloudflare integration for speed and security
  • Global audience reach with up to 35 data centers and 275 PoPs worldwide

Test it yourself with $20 off your first month of Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.


Linux, Программное обеспечение

  • 21.01.2015
  • 35 068
  • 5
  • 03.04.2020
  • 22
  • 21
  • 1

Исправляем ошибку: 413 Request Entity Too Large

  • Содержание статьи
    • Описание ошибки
    • nginx
    • Apache
      • httpd.conf
      • .htaccess
    • PHP
    • Комментарии к статье ( 5 шт )
    • Добавить комментарий

Описание ошибки

413 Request Entity Too Large

Данная ошибка может появиться в том случае, если вы загружаете какой-либо файл на сервер и размер этого файла превышает максимально разрешенный в конфиге в веб-сервера (например, в nginx по умолчанию установлено ограничение в 1 МБ).  Для того, чтобы это исправить, необходимо внести определенные правки в файл конфигурации, который может быть разным, в зависимости от используемого веб-сервера. Ниже будут приведены примеры для самых популярных веб-серверов:

nginx

Максимальный размер файла указывается параметром client_max_body_size. Поэтому, достаточно прописать параметр и новое значение в любой конфиг, который использует nginx для сайта, на котором у вас появилась эта проблема. Получится должно что-то примерно следующее:


server {
    ...
    client_max_body_size 4m;
    ...
}

Где 4m — это 4 Мб. Для установки лимита в 32 Мб, надо соответственно написать client_max_body_size 32m, и т. д.

После изменения настроек нужно обязательно перезагрузить конфиг в nginx.

Apache

httpd.conf

Размер файла, допустимого для заливки, можно отрегулировать в главном конфиге Apache, который можно найти по адресу /etc/httpd/conf/httpd.conf (в CentOS) или /etc/apache2/apache2.conf (в Debian/Ubuntu). Задается он параметром LimitRequestBody, и ему можно прописать любое нужное значение в байтах. Например, так выглядит ограничение в 32 МБ:

LimitRequestBody 33554432

Для применения настроек нужно перезагрузить веб-сервер Apache.

.htaccess

Очень часто у веб-сервера Apache для настройки определенного сайта используется файл .htaccess, который лежит в корневой директории веб-сайта. Удобство данного метода в том, что Вы можете прописать нужные настройки, которые будут применяться только для данной директории и веб-сайта, который данную директорию использует.

Если используемый для загрузки скрипт находится в какой-то поддиректории, где имеется свой файл .htaccess, то его настройки будут иметь больший приоритет!

Для этого, нужно либо открыть уже существующий файл .htaccess (или создать, в случае отсутствия) и добавить туда следующие строки (32 МБ в байтах):

LimitRequestBody 33554432

Если для работы сайта и заливки файла используется PHP, то нужно добавить еще другую строчку:

php_value upload_max_filesize 32M

PHP

Если при заливке файла используется PHP скрипт, то для PHP имеются отдельные настройки максимального размера файла. Для их изменений потребуется внести правку в файл php.ini, который расположен по адресу /etc/<версия php>/fpm. Открываем его любым текстовым редактором и находим следующие строки:

upload_max_filesize
post_max_size

И выставляем им нужные значения, например 4M (т. е. 4 МБ).

После внесения правок просто перезагружаем php, и проверяем работу.

Are you also one of those who couldn’t find any right guide and solution for fixing HTTP Error 413? That’s an error. Your client issued a request that was too large. That’s all we know. Chrome Browser code problem. Then check out this post below to find the best guide and the right method for this error problem. So check out this once,

It shows an error code message like;

Error 413

HTTP Error 413. That’s an error. Your client issued a request that was too large. That’s all we know.

This error indicates that the request was larger than the server could handle due to physical constraints or settings. It is a very common error in Nginx. The server may close the connection from this error to prevent the client from continuing the request. It can be fixed by increasing the memory limit in Nginx and the PHP configuration file. This Error 413 occurred in Windows PC users mostly.

Causes of HTTP Error 413 That’s an Error Chrome Issue:

  • Client NIL has too much post data
  • Request entity too large Apache
  • Visitor NIL large file
  • Google Chrome browser error issue
  • User authentication failed
  • HTTP error problem

So, here are some guidelines and the top best guide methods for getting rid of this type of HTTP Error 413. That’s an error. Your client issued a request that was too large. That’s all we know about Chrome Browser code problems for you permanently.

How to Fix HTTP Error 413 That’s an Error That’s all we know Chrome Issue

1. Modify the PHP.ini file for Upload limit –

Modify PHP.ini file for Upload limit Error 413

  • If you are using PHP, use the following command,
    nano /etc/php.ini
  • If you are using PHP_FPM, use the following command,
    nano /etc/php5/fpm/php.ini
  • Now, find the following directions one by one
    upload_max_filesize
    post_max_size
  • & increase its limit to 100M (By default, they are 8M to 2M)
    upload_max_filesize = 100M
    post_max_size = 100M
  • Finally done, now save it
  • Restart PHP
**NOTE: (You can set any limit to Nginx & PHP configuration files)

By Modifying the PHP.ini file for Upload limit, you can quickly fix this Error 413. That’s an error. Your client issued a request that was too large. That’s all we know. The problem with you.

2. Modify the Nginx Configuration file on your Device –

Modify Nginx Configuration file

  • Edit Nginx.Conf file
    nano /etc/Nginx/Nginx.conf
  • Search for this variable
    client_max_body_size
  • If you find it, increase its size to 100M,
  • If it doesn’t exist, then you can add it inside Http { } block
    client_max_body_size 100M;
  • Restart Nginx to apply the changes
    sudo service Nginx restart

Modifying the Nginx Configuration file can quickly get rid of this Error 413. That’s an error. Problems.

3. Clear the Browsing Data and History from your Internet Browser –

Clear Browsing History Error 413

  • Go to the Internet Explorer browser
  • Click & open it
  • Click on the Tools button & move to safety
  • Then, click on the ‘Delete Browsing History.’
    (Select the type of data that you want to remove)
  • Now, click on “Delete.”
  • That’s it, Done

By clearing the internet explorer browser browsing history, you can get back from this Dropbox Error 413 problem successfully.

” OR “

  • Go to the Google Chrome browser
  • Click on the (3 layer lines) on the upper right side
  • Click on the Settings button there
  • Go to the history option there
  • Click on ‘Clear Browsing History.’
  • Select the types of data you want to remove
  • Now, select ‘Clear Browsing History.”
  • That’s it, Done

Clearing the browsing history from the google chrome browser will fix this Error 413 request entity too large code problem quickly from you.

4. Setup the Maximum Transmission Unit (MTU) in CMD (Command Prompt) –

Setup Maximum Transmission Unit (MTU)

  • Go to the start menu
  • Type ‘run‘ there & click on it
  • Open it & type ” ncpa.cpl ” there
  • Click on the OK button or press enter there
  • A pop-up will open, and you will see the wireless networks there
  • Again go to the Run & open it
  • Type “cmd” there & press ok
  • In the Command prompt, type the following command
    netsh interface IPv4 set subinterface “Wireless Network Connection 4” mtu=1472 store=persitent
  • Replace the Local Area Connection with the name of your network adapter
  • Then, Press Enter
  • That’s it, Done

Running this (MTU) Maximum Transmission Unit command will fix this Error 413 entity too large problem.

5. By netsh Winsock reset Method in Cmd (Command Prompt) –

By netsh winsock reset Method in Cmd Error 413

  • Go to the start menu
  • Search or type cmd there
  • Go to the cmd & right-click on it
  • Then, click on ‘Run as administrator.’
  • Type ” netsh Winsock reset ” & press enter there
  • Restart your computer again
  • That’s it, done

By netsh Winsock reset command, it will fix this Error 413 google code problem.

6. Check the Internet Proxy Settings on your Windows PC –

Check Proxy Settings

  • Go to the start menu
  • Click on the control panel
  • Open it
  • Go to the Internet options there
  • Click on it & a pop-up will open
  • Go to the Connections tab there
  • Click on LAN setting there
  • deselect the “Use a proxy server for your LAN” option there if it is ticked
  • Then, Click on the OK button there
  • That’s it, done

Deselecting the settings will solve this Error 413 user authentication failed code problem.

7. Flush the Socket Pools from your Google Chrome Browser –

Flush Socket Pools Error 413

  • Go to the start menu
  • Go to your browser
  • Clicks on it and opens it there
  • Type the following command there in their address bar
    chrome://net-internals
  • Press Enter & click on the drop-down menu there
  • Select ‘Sockets‘ from the drop-down list
  • Click “Flush Socket Pools” on it there
  • After completing, close the tab
  • That’s it, done

By flushing the socket, pools can quickly fix and solve this Error 413, that’s an error your client issued a request that was too large. That’s all we know about code problems from your PC browser.

8. Turn OFF or Disable Windows Firewall Settings on your Windows PC –

Turn Off or Disable Windows Firewall Settings

  • Go to the Start Menu
  • Go to the Control Panel
  • Click on Windows Firewall there
  • Click on the ‘Turn Windows Firewall on or off feature there
  • Tick on “Turn off Windows Firewall (not recommended)” there
  • Now, Click on the ‘OK‘ button there
  • That’s it, Done

Turning off or disabling the windows firewall settings can fix this Error 413; that’s an error problem.

9. Reinstall Network Adapter on your Windows PC –

Reinstall Network Adapter Error 413

  • Go to the start menu
  • Search or go to the ‘RUN.’
  • Click on it and opens it.
  • After that, Type this below the following command there
    hdwwiz.cpl
  • Press Ok there
  • Expand network adapters, locate your network adapter name
  • Note down the name,
  • Right-click on that adapter
  • Choose and click on the Uninstall option there
  • Reboot or restart your PC once
  • After resuming, reconnect to your network & test
  • If it is not installed, then download it from the manufacturer’s website
  • After that, run it and reinstall it
  • After that, test it
  • After completing, close the tab
  • That’s it, done

By reinstalling the network adapter, you can get rid of this Error 413 request entity too large code problems.

Conclusion:

These are some top best tricky ways and practical solutions for fixing and solving this HTTP Error 413. That’s an error. Your client issued a request that was too large. That’s all we know Chrome Browser code problem from your PC permanently. Hope it will help you eliminate this Error 413 code problem.

If you are facing this HTTP Error 413. That’s an error. Your client issued a request that was too large. That’s all we know about Chrome Browser code problems or any error problem while fixing Error 413; then comment down the problem below so that we can fix and solve it too by our tricky solution methods guides.

FSCUT1000S Laser Cutting Control System User Manual

5

5.1.12 Following deviation is too large…………………………………………………………………. 74

5.1.13 Use period has expired……………………………………………………………………………….74

5.1.14 Move close to board…………………………………………………………………………………..74

5.1.15 Network Alarm………………………………………………………………………………………… 74

5.2 Analysis of common problems…………………………………………………………………………….. 75

5.2.1 There is obvious shaking and mechanical impact when Z axis in following

movement……………………………………………………………………………………………………75

5.2.2 Collision in following mode………………………………………………………………………… 75

5.2.3 Following distance different with the actual setting……………………………………….. 76

5.2.4 Lifting height not right…………………………………………………………………………………76

5.2.5 Upgrade prompt «Check error, ARM upgrade failed»………………………………………76

Решение вопроса с одной ошибкой BCS100 (или невмеру шустрых рук оператора)

На лазере оператор вместо того что-бы произвести калибровку емкостного датчика уровня на автомате понажимал и изменил параметры не в тех менюшках BCS-100.

В попытке исправить что-то еще наделал где-то. В итоге когда позвал на станке висит ошибка Z servo alarm, головка поднялась до самого верха — дошла до концевика и остановилась с ошибкой.

Координаты Z ушли в минус. На вопрос нафига он это делал — вразумительного ответа не дал. Думал что поправит самостоятельно…. больше напортачил.

Выключили станок — гаечным ключем опустили головку поворотом ходового винта — снять из зоны действия концевика — включили станок. Нажимаем вниз — он вместо того что-бы идти вниз идет рывком вверх.

Мы понимаем что координаты Z сбились, калибровка сервопривода не соотвествует. Попытка нажать калибровка сервопривода выдает Calibrate fail. Pos deviation large.

Связались с сервис инженером производителя станка.

после переписки входим меню F2 параметры, нажимаем 5, нажимаем Enter

Direction of servo стоит 1  меняем на 0 и нажимаем Enter что-бы сохранить

выходим из меню, головка начала слушаться и медленным опусканием опускаем головку до касания с листом — она начинает подниматься. Затем нажимаем Origin она встает в 0 позицию.

Z параметры становятся плюсовыми и легкое сумасшествие проходит. Лазер вернулся в строй.

Как потом оказалось вместо F1 калибровка оператор нажал F2 параметры и на автомате нажал 2 и сбросил значение скорости (200мм/c в нашем случае) на 2. Все делал на автомате — поэтому не запомнил что и где он делал. И при Edge seekeng скорость так сильно замедлилась что он решил что все сломалось. Ну и наделал делов. Провели внеочередной инструктаж операторам по параметрам BCS100. Куда лезть а куда не надо.

Кстати когда станок пришел я снял резервную копию компьютера станка, а резервную копию параметров BCS не делал. Понял что зря я об этом не подумал. На повторный запуск станка ушло пол дня. Рекомендую от шаловливых ручек сфотографировать все страницы параметров. Резервная копия параметров с BCS на usb флэшку у нас почему-то не работает.  пишет USB initalizing  и стоит.   

Environment:

  • Fail2Ban version : 0.11.2-2
  • OS, including release name/version : debian bullseye
  • Fail2Ban installed via OS/distribution mechanisms
  • You have not applied any additional foreign patches to the codebase
  • Some customizations were done to the configuration (provide details below is so)

The issue:

After restarting mumble-server (aka murmurd) fail2ban complains that the deviation is too large (see log excerpt below).

Steps to reproduce

Install fail2ban and mumble-server, enable murmur jail, restart fail2ban, restart mumble-server.

Expected behavior

No warnings in fail2ban.log.

Observed behavior

fail2ban complains, probably because it can’t find the timestamp in the log line.

Any additional information

I have a suspicion that it’s a simple pattern matching issue: /etc/fail2ban/filter.d/murmur.conf has __prefix_journal = (?:S+s+%(_daemon)s[d+]:(?:s+<W>[d-]+ [d:]+.d+)?) and datepattern = ^<W>{DATE}, which means any other mumble-server log level (e.g. C or X, not W) won’t match the fail2ban’s line/timestamp expectations.

Configuration, dump and another helpful excerpts

Relevant parts of /var/log/fail2ban.log file:

2022-03-27 10:16:30,993 fail2ban.filter         [22254]: WARNING [murmur] Simulate NOW in operation since found time has too large deviation None ~ 1648376190.9936266 +/- 60
2022-03-27 10:16:30,994 fail2ban.filter         [22254]: WARNING [murmur] Please check jail has possibly a timezone issue. Line with odd timestamp: <C>2022-03-27 10:16:30.964 Caught SIGTERM, exiting

Relevant lines from monitored log files:

<C>2022-03-27 10:16:30.964 Caught SIGTERM, exiting
<W>2022-03-27 10:16:30.964 Killing running servers
<W>2022-03-27 10:16:30.971 1 => Stopped
<W>2022-03-27 10:16:30.972 Shutting down
<X>2022-03-27 10:16:31.022 SSL: OpenSSL version is 'OpenSSL 1.1.1n  15 Mar 2022'
<W>2022-03-27 10:16:31.022 Initializing settings from /etc/mumble-server.ini (basepath /etc)
<W>2022-03-27 10:16:31.706 ServerDB: Opened SQLite database /var/lib/mumble-server/mumble-server.sqlite
<W>2022-03-27 10:16:31.709 ServerDB: Using SQLite's default rollback journal.
<W>2022-03-27 10:16:31.780 Murmur 1.3.4 (1.3.4-1) running on X11: Debian GNU/Linux 11 (bullseye): Booting servers
<W>2022-03-27 10:16:31.787 1 => Server listening on 0.0.0.0:64738
<W>2022-03-27 10:16:32.422 1 => Not registering server as public

  • Index
  • Recent Topics
  • Search
  • www.linuxcnc.org
  1. Configuring LinuxCNC

  2. PnCConf Wizard

  3. Lichaun LCDA357H setup


19 Oct 2020 18:35 #186601
by CaspianCmonster

Hi everyone, I have just managed to get my router wired up but am not getting it to work. I have a Mesa 5i25+7i76 with three Lichaun drives and motors (three phase closed loop steppers) running a small CNC router (Karla).

I used PNCconfig with default values for properties of the steppers etc. When I try to jog any of the axes it moves a bit, loudly and the driver starts flashing an error (3 blinks) and everything stops. it is the same on all three axes. The driver manual doesn’t tell me what that means which is not very impressive.

I am not sure where to start looking. I used this hardware (computer and mesa cards) many years ago with conventional steppers and it worked without major issues so I suspect something I am sending the drives is way off.

the firmware is old (2016 I think) but I doubt that is the issue.

the drives are set at 1000 steps per rev.

Please Log in or Create an account to join the conversation.


19 Oct 2020 19:0319 Oct 2020 19:04 #186605
by PCW

Your Y and Z accelerations (10X the X accel) probably exceed the drives capabilities

Last edit: 19 Oct 2020 19:04 by PCW.

Please Log in or Create an account to join the conversation.


19 Oct 2020 19:07 #186606
by CaspianCmonster

Thanks PCW, I was testing if the acceleration was the issue, even with the lower acceleration the X still doesn’t work.

I am regretting getting these drives, the documentation is really no good.

Luke

Please Log in or Create an account to join the conversation.


19 Oct 2020 19:42 #186610
by PCW

You might try setting the direction setup and hold times to 20000
just to guarantee that these are not being violated and perhaps also
try inverting the step output

Please Log in or Create an account to join the conversation.


19 Oct 2020 20:08 #186612
by Hakan

You might also try to flip SW6 to switch off the encoder feedback and turn them into normal stepper motors. In case there is something with the encoder feedback I mean.
I found three error codes, perhaps you get the one with seven flashes in the manual which is positional deviation is too large but it is a guess since you see three flashes.

www.hardware-cnc.nl/images/PDF/lichuan/0411c22cd045b8c35909.pdf

Please Log in or Create an account to join the conversation.


20 Oct 2020 09:44 #186663
by CaspianCmonster

Thanks Hakan, I didn’t realize this was an option. (my drivers came direct from China so the last two dip switches are not labeled in characters I can read :)

With #6 switched off I have the three axes moving in a reasonable fashion. I guess now I need to see what is wrong with the encoders. they came wired when delivered but I am going to guess that they were not done correctly.

Luke

Please Log in or Create an account to join the conversation.


20 Oct 2020 14:06 #186682
by Reinhard

my drivers came direct from China so the last two dip switches are not labeled in characters I can read

But you can download the
manual from LiChuan
, where you find a description of switches 5 (motor direction) and switch 6 (open/closed loop).

These are the error codes of LiChuan driver:

Alarm LED

flashing times - problem description
------------------------------------
 1  over current
 2  over speed
 3  loose step
 4  over load
 5  driver too hot
 6  over voltage
 7  motor connection error
 8  encoder connection error
 9  low voltage
10  Position deviation is too large

So your 3-time blinking code means loose of steps — which in turn means, that the mechanic is too hard to move for the motor, your commanded speed is to high or your encoder feedback is weird.

I cutted of the default plug and connected the encoder to the driver with individual cables …
Colors of encoder cable (from motor) are:

  • blue — EA-
  • black — EA+
  • red — VCC
  • white — GND
  • green — EB-
  • yellow — EB+

TIP: use pncconf to test axis movements. There you can easily change motor/driver settings and see, what values work with your machine.

Please Log in or Create an account to join the conversation.


26 Oct 2020 14:04 #187310
by CaspianCmonster

After much messing around and talking with some other people I finally got this working. The encoder wiring was wrong in the data sheets and the wire colors have changed over time.

I was able to find the correct pin numbers for each encoder wire and get them working properly.

(for the record they are as follows, the plugs are labeled but it isn’t easy to read them.

EA+ = 1
EA- = 2
EB+ = 4
EB- = 5
Gnd = 7
Vcc = 8

Anyway the router is moving at 13m/min for rapids without errors which is ok for a little machine like this. Not that I have the spindle power to cut at anywhere near that fast. I seem to remember the big industrial router I worked with in grad school cut a stack of of plywood at 1200 inch/min which is 30m/min! It was just a little more powerful :)

Please Log in or Create an account to join the conversation.


01 Feb 2021 00:59 #197265
by Pala2020

Good morning.
I am having the same problem that they are discussing here … I tried what they suggest but it doesn’t work for me.
could you help me …. I’m a bit frustrated … thanks

Please Log in or Create an account to join the conversation.


01 Feb 2021 09:33 #197293
by tommylight

Upload the config files here and pictures of how the drives are wired to the 7i76.

Please Log in or Create an account to join the conversation.

  1. Configuring LinuxCNC

  2. PnCConf Wizard

  3. Lichaun LCDA357H setup

Time to create page: 0.263 seconds

Понравилась статья? Поделить с друзьями:
  • Fog lamp ситроен ошибка
  • Fog lamp опель астра h ошибка
  • Fo6 ошибка на стиральной машине hotpoint ariston
  • Fo5 ошибка стиралка индезит
  • Fo5 ошибка стиралка аристон