Following code gives me the error ‘Buffer full’ and I have no idea why. My code was supposed to give me wave chart while it’s recording the audio. However, wave chart is working and the after 5 seconds above error is brought to the screen my the program
I’m new to this.
private void btnRecord_Click(object sender, EventArgs e)
{
if (btnRecord.Text == "Record")
{
sources = new List<NAudio.Wave.WaveInCapabilities>();
for (int i = 0; i < NAudio.Wave.WaveIn.DeviceCount; i++)
{
sources.Add(NAudio.Wave.WaveIn.GetCapabilities(i));
}
input = new NAudio.Wave.WaveIn();
input.DeviceNumber = 0;
input.WaveFormat = new NAudio.Wave.WaveFormat(44100, NAudio.Wave.WaveIn.GetCapabilities(0).Channels);
NAudio.Wave.WaveInProvider waveIn = new NAudio.Wave.WaveInProvider(input);
waveOut = new NAudio.Wave.DirectSoundOut();
waveOut.Init(waveIn);
input.StartRecording();
//waveOut.Play();
input.DataAvailable += input_DataAvailable;
btnRecord.Text = "Stop Record";
}
else if (btnRecord.Text == "Stop Record")
{
waveOut.Stop();
input.StopRecording();
btnRecord.Text = "Record";
input.Dispose();
}
}
private void input_DataAvailable(object sender, WaveInEventArgs e)
{
MemoryStream memStream = new MemoryStream();
memStream.Write(e.Buffer, 0, e.BytesRecorded);
RawSourceWaveStream rawSource = new RawSourceWaveStream(memStream, input.WaveFormat);
customWaveViewer2.WaveStream = rawSource;
rawSource.Flush();
memStream.Flush();
}
The following would be stacktrace
at NAudio.Wave.BufferedWaveProvider.AddSamples(Byte[] buffer, Int32 offset, Int32 count)
at NAudio.Wave.WaveInProvider.waveIn_DataAvailable(Object sender, WaveInEventArgs e)
at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
at NAudio.Wave.WaveIn.RaiseDataAvailable(WaveInBuffer buffer)
at NAudio.Wave.WaveIn.Callback(IntPtr waveInHandle, WaveMessage message, IntPtr userData, WaveHeader waveHeader, IntPtr reserved)
at NAudio.Wave.WaveWindow.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
at Pitch_Comparer.Program.Main() in c:UsersNadeeshaDocumentsVisual Studio 2012ProjectsPitch_ComparerPitch_ComparerProgram.cs:line 19
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Uploading large files in HTTP multipart POST requests fails with multipart: NextPart: bufio: buffer full.
What version of Go are you using (go version)?
go version go1.10.3 linux/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ulfr/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ulfr"
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build508991886=/tmp/go-build -gno-record-gcc-switches"
What did you do?
The following source code accepts uploads requests over HTTP. It works fine for files up to 15GB, but crashes for 20GB files with the error: multipart: NextPart: bufio: buffer full
package main import ( "log" "net/http" ) func main() { http.HandleFunc("/upload", uploadHandler) http.ListenAndServe(":5050", nil) } func uploadHandler(w http.ResponseWriter, r *http.Request) { log.Printf("%s %s %s user-agent=%s", r.Method, r.Proto, r.URL.String(), r.UserAgent()) if r.Method != http.MethodPost { http.Error(w, "only POST method is allowed", http.StatusBadRequest) return } log.Printf("parsing multipart form") // no more than 100MB of memory, the rest goes into /tmp r.ParseMultipartForm(100000000) file, handler, err := r.FormFile("uploadfile") if err != nil { http.Error(w, "failed to read uploadfile form field", http.StatusBadRequest) log.Printf("failed to read uploadfile form field: %v", err) return } defer file.Close() log.Println(handler.Filename) }
Here’s an example run with a 20GB file filed with zeroes.
$ go run multipart.go
2018/07/31 08:29:18 POST HTTP/1.1 /upload user-agent=curl/7.59.0
2018/07/31 08:29:18 parsing multipart form
2018/07/31 08:29:43 failed to read uploadfile form field: multipart: NextPart: bufio: buffer full
upload with curl:
$ curl -vi -F uploadfile="@/home/ulfr/20gfile.bin" http://127.0.0.1:5050/upload * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 5050 (#0) > POST /upload HTTP/1.1 > Host: 127.0.0.1:5050 > User-Agent: curl/7.59.0 > Accept: */* > Content-Length: 20971520209 > Content-Type: multipart/form-data; boundary=------------------------879658a7528de349 > Expect: 100-continue > < HTTP/1.1 100 Continue < HTTP/1.1 400 Bad Request < Content-Type: text/plain; charset=utf-8 < X-Content-Type-Options: nosniff < Date: Tue, 31 Jul 2018 12:29:43 GMT < Content-Length: 37 < Connection: close < failed to read uploadfile form field * we are done reading and this is set to close, stop send * Closing connection 0
Since my machine has 32GB of RAM, I tried boosting MAXMEMORY to 30GB by setting r.ParseMultipartForm(3000000000) but got the same results.
| Автор | Сообщение |
|---|---|
|
Заголовок сообщения: Проблема: DGS-36xx и Buffer Full Drop
|
|
|
|
В DGS-3627G в 23 порт поступает поток с DGS-3100-24 (несколько тагированных VLAN-ов, multicast). Соединение оптическое через модули. При превышении потока ~ 800-850 Mbit (110000-120000 Frames) начинаются ошибки Buffer Full Drop.
Boot PROM Version : Build 1.10-B09 Что нужно предпринять для устранения этой проблемы? |
| Вернуться наверх |
|
 |
Добавлено: Пн ноя 01, 2010 12:00 
|
lacost |
Заголовок сообщения:
|
|
|
Дополнение по теме. Аналогичная проблема наблюдается на 2 независимых коммутаторах. при приближении к 850-900 Мбит — начинаются дропы. Модули SFP OptiCin. Меняли модули местами, ставили новые. Проблема остается и повторяется. |
| Вернуться наверх |
|
|
|
Bigarov Ruslan |
Заголовок сообщения:
|
|
|
Тестировали: гоняли трафик с гигабитного порта на гигабитный?
Приведите, пожалуйста, пример вывода команд: _________________ |
| Вернуться наверх |
|
|
|
lacost |
Заголовок сообщения:
|
|
|
Нет, не тестировали а реально работаем. И вечерами, в ЧНН начинаются проблемы. Перезагрузка помогает. Но я думаю только из-за того что сессии падают, и нагрузка спадает. Вот вывод со свича:
DGS-3627G:5#sh packet ports 23
Port number : 23
Frame Type Total Total/sec DGS-3627G:5#sh error ports 23 Port number : 23 |
| Вернуться наверх |
|
|
|
Bigarov Ruslan |
Заголовок сообщения:
|
|
|
Buffer Full Drop обычно растут, когда трафик льётся в какой-то узкое место и буфера коммутатора не хватает, так как входящий поток превышает в несколько раз. _________________ |
| Вернуться наверх |
|
|
|
lacost |
Заголовок сообщения:
|
|
|
Полки на графиках нет. Я понимаю, если бы была полка и пошли бы дропы…. Что можно предпринять? куда смотреть? |
| Вернуться наверх |
|
|
|
Bigarov Ruslan |
Заголовок сообщения:
|
|
|
Как вариант приоритезировать Интернет трафик, служебный, IPTV & VoIP, и ограничеть полосу пропускания для локального трафика. _________________ |
| Вернуться наверх |
|
|
|
lacost |
Заголовок сообщения:
|
|
|
Ruslan, я понял, если бы была полка. Тогда приоритеты и все прочее. Могу выложить (или выслать на почту) график загрузки портов. |
| Вернуться наверх |
|
|
|
Bigarov Ruslan |
Заголовок сообщения:
|
|
|
Зайдём с другой стороны, у Вас Intranet трафик не закрыт, т.е. клиенты внутри локальной сети могут спокойно общаться и меняться файлами?! _________________ |
| Вернуться наверх |
|
|
|
lacost |
Заголовок сообщения:
|
|
|
Да, конечно интранет есть. Только не вижу как он здесь влияет?
Есть коммутатор, 24 порта. И я так понимаю, что если на порт 1Гб попытаться подать 1,3 Гб, то на графике я увижу полку а не провал на 20-30 процентов? Или как? |
| Вернуться наверх |
|
|
|
shicoy |
Заголовок сообщения:
|
|
|
lacost писал(а): И я так понимаю, что если на порт 1Гб попытаться подать 1,3 Гб, то на графике я увижу полку а не провал на 20-30 процентов? Или как? Смотря какими пакетами. Посмотрите размеры пакетов на 23,24 порту во время возникновения такой ситуации |
| Вернуться наверх |
|
|
|
lacost |
Заголовок сообщения:
|
|
|
Да, наблюдается большое количество мелких пакетов. Но, цепочка такая: DGS-3100-24 в 21 и 22 порты получает трафик и в 23 выливает его в DGS-3627 в 23 порт. DGS3627 в свою очередь переливает этот трафик с 23 в 24 порт.
Так вот. Так получается? |
| Вернуться наверх |
|
|
|
Bigarov Ruslan |
Заголовок сообщения:
|
|
|
Суть в том, что трафик с нескольких портов может предназначаться одному порту, в таких случаях буфер может не справляться и как результат отбрасывать трафик. _________________ |
| Вернуться наверх |
|
|
|
Maxim Klyus |
Заголовок сообщения:
|
|
|
2 lacost какое устройство подключено к порту 24 коммутатора DGS3627 ? |
| Вернуться наверх |
|
|
|
lacost |
Заголовок сообщения:
|
|
|
К 24 порту DGS3627G подключен DGS3612 через sfp. Flow control выключен везде. Я все понимаю что если подать много — будут дропаться пакеты. Но повторюсь. 3100 смог отдать через гиговый порт трафик порядка 800-900 мбит, а 3627 через гиговый порт принять не смог. так получается? Дропы идут на 23 порту 3627 |
| Вернуться наверх |
|
|
Помогите, пожалуйста, разобраться со следующей проблемой.
При подключении lan-кабеля в роутер (интернет > роутер > компьютер по кабелю), периодически пропадает интернет, на стороне провайдера видны ошибки и т.д., на какое-то время помогает перезагрузка роутера.
Казалось бы, очевидно проблема в роутере, но.
Проблема началась с роутера TP-LINK TL-WR841N, отдал его другу, и взял Cisco LinkSys EA3500 (работающий на другом провайдере у друга без проблем вообще), и опять та же проблема. Но только LinkSys не требовалось перезагружать, достаточно передёрнуть кабель (его видят ноут, телефоны и т.д., а интернета нет, т.е. роутер вроде как не зависает).
Ок, взял у соседа другой TP-LINK, ему отдал свой Cisco. У соседа целый день всё ок, у меня те же проблемы.
Подключаю lan-кабель напрямую в компьютер — ни ошибок, ни проблем.
Провайдер соответственно не может выяснить в чём проблема, т.к. напрямую всё ок.
Не знаю связанно ли это или нет, но проблемы начались после полной смены сетапа (был интел, стал амд). Может ли компьютер (его сетевая карта) как-то влиять на роутер?
Даже не знаю за что зацепиться, куда смотреть. Сейчас основной роутер это Cisco LinkSys EA3500. Есть какие-то мысли на этот счёт?
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
У друга и соседа один и тот же провайдер, не такой как у меня.
Отправлено спустя 1 минуту 52 секунды:
Во время пропадания интернета (не зависания роутера/ов) по вайфаю интернет тоже пропадает, хотя все устройства видят роутер/ы.
Отправлено спустя 29 секунд:
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
Уверен, у него проц не более 600-800Мгц, и скорее 1 ядро всего, если запросы летят напрямую к цпу ( широковещалки броадкаста или еще какая дрянь ) то в лучшем случае он будет заметно плохо жевать трафик, в худшем повесится, и скорее повесится еще и от перегрева.
Увы я уважаю только среднецоновой и выше сегмент микротик, циско, джунипер или полноценный боард сервер на линукс etc., с нормальными сетевыми.
Линксис — огрызок циски, не более.
Отправлено спустя 1 минуту 15 секунд:
А по arp -a выдаёт 11 адресов.
тут бы глянуть что от них летит еще
Отправлено спустя 3 минуты 16 секунд:
Попросите КЦ провайдера соединить с тех.отделом.
Тех.отдел попросите переселить вас в другой сегмент сети, зачастую в другой VID, сообщите то что описали тут.
Как подтвердят что сделали — пробейте снова arp -a, гляньте правда ли, или врут.
Если выполнили требования — наблюдайте за инетом.
Самый простой способ проверить что не так, если поддержка у провайдера адекватна.
Отправлено спустя 7 минут 18 секунд:
Ах да, еще момент, вы уверены что вешается роутер не от вашего ПК?
Банальная проверка на вирусню с помощью cureit!, и сброс сетевого стека, в командной строке:
netsh winsock reset
netsh int ip reset
Думаю не повредят, только после команд настроек на сетевой не будет, так что если у вас статический IP их следует записать.
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
papamama: Помогите, пожалуйста, разобраться со следующей проблемой.
При подключении lan-кабеля в роутер (интернет > роутер > компьютер по кабелю), периодически пропадает интернет, на стороне провайдера видны ошибки и т.д., на какое-то время помогает перезагрузка роутера.
Какие ошибки?
Для понимания:
CRC Error 7 Excessive Deferral 0
Undersize 0 CRC Error 0
Oversize 0 Late Collision 0
Fragment 1 Excessive Collision 0
Jabber 0 Single Collision 0
Symbol Error 4 Collision 0
Buffer Full Drop 101629 STP Drop 18065
ACL Drop 0 HOL Drop 0
Multicast Drop 0
VLAN Ingress Drop 22332842
Invalid IPv6 0
STP Drop 6595
Storm and FDB Discard 0
MTU Drop 0
Вот их сколько разных, и это только малая капля на недосвитче Dlink, стянул с первого попавшегося под руку коммутатора статистику рандомного порта.
Самые распространенные:
CRC — ошибки контрольной суммы, пакеты бьются не долетая к вас/ от вас
Fragment — то же самое, но когда идет дробление больших пакетов на более мелкие, мало вероятно
Collision — столкновение пакетов из-за несогласованности меж отправитиелем и получателем
acl drop — отброс пакета согласно установленных «правил» свитча, это настройка провайдера
STP drop — дропы лишних stp пакетов, когда STP выключен, или пакеты STP не распознаны
Storm and FDB Discard — дропы согласно встроенных механизмов защиты коммутатора от шторма и петли
MTU drop — дропы из-за несогласованности MTU
Так вот, если прут CRC, Fragment, Collision, просим провайдера проверить длину и целостность кабеля, при наличии норм коммутаторов они это могут, и просим назвать сколько.
Если кабеля больше 70м, не исключено что просто не пробивает, или плохой кабель, просим заменить
Типы ошибок (dlink)
Undersize — возникают при получение фрейма размером 61-64 байта.
Фрейм передается дальше, на работу не влияет
Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой
Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме
Drop Pkts — пакеты отброшенные в одном из трех случаев:
Какие пакеты входят в Drop Packets при выводе show error ports?
Переполнение входного буфера на порту
Пакеты, отброшенные ACL
Проверка по VLAN на входе
Fragment — количество принятых кадров длиной менее 64 байт (без преамбулы и начального ограничителя кадра, но включая байты FCS — контрольной суммы) и содержащих ошибки FCS или ошибки выравнивания.
Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.
Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред
Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета
Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончались неудачей. данный пакет больше не передается
Why do UDP packets get dropped?
The first time I heard this joke I did not understand it because I didn’t really understand what UDP was. UDP is a network protocol. The deal is: I send you a network packet. Maybe you get it, maybe you don’t. I have no idea whether it arrived or not. UDP doesn’t care.
When you’re losing UDP packets, it’s sort of tempting to say “well, whatever, that’s what happens when you use UDP!” But UDP packets don’t get lost by magic.
I was pretty confused about some the details of dropping UDP packets (how do you know how many packets got dropped? what causes a packet to be dropped exactly?) Maggie Zhou (who is the best) explained some new things to me today! All the parts of this that are right are thanks to her and all the parts that are wrong are thanks to me.
This is all on Linux, as usual. There are going to be sysctls! It will be the best.
lost on the way out
Imagine you’re sending a lot of UDP packets. Really a lot. On every UDP socket, there’s a “socket send buffer” that you put packets into. The Linux kernel deals with those packets and sends them out as quickly as possible. So if you have a network card that’s too slow or something, it’s possible that it will not be able to send the packets as fast as you put them in! So you will drop packets.
I have no idea how common this is.
lost in transit
It’s possible that you send a UDP packet in the internet, and it gets lost along the way for some reason. I am not an expert on what happens on the seas of the internet, and I am not going to go into this.
lost on the way in
Okay, so a UDP packet comes into your computer. You have an application that is listening and waiting for a packet. Awesome! This packet goes into – maybe you guessed it – a socket receive buffer. How big is that buffer? Everything you might want to know about socket send and receive buffer sizes is helpfully explained in the man page for socket . Here’s the maximum receive buffer size on my computer:
man udp says that that last number from net.ipv4.udp_mem (362220) means “Number of pages allowed for queueing by all UDP sockets.” 362220 pages is 1.7GB? That’s a lot of pages! Weird. Not sure what’s up with that.
Then your application reads packets out of that buffer and handles them. If the buffer gets full, the packets get dropped. Simple!
You can see how many packets have been dropped on your machine with netstat -suna . Mine has dropped 918 packets so far apparently (“918 packet receive errors”)
This is cool! This means that if you have a machine which is trying to drop as few UDP packets as possible (for instance if you’re running statsd), then you can monitor the rate at which that machine is dropping packets!
buffers everywhere
After I published this blog post initially, @gphat and @nelhage very astutely pointed out that the OS socket send/receive buffers are not the only buffers.
EVERYTHING IS BUFFERS. Your network card has a buffer that can get full! There are a bunch of intermediate routers between your computer and my computer. All of those have buffers! Those buffers can get full! My current understanding is that most packet loss is because of full buffers one way or another.
If you’re interested in learning more details about the Linux networking stack, there is this huge post called Monitoring and Tuning the Linux Networking Stack: Receiving Data. I have not read it yet but it looks amazing.
Also everything here I said about UDP packets applies just as well to any kind of IP packet – TCP packets can get dropped just as easily, but they’ll get retried, so you’re not as likely to notice.
Discussions about chromatography data systems, LIMS, controllers, computer issues and related topics.
-
- chloesabrina
-
- Posts: 59
- Joined: Thu Aug 02, 2007 3:19 pm
We have had a ongoing problem in our lab with our Agilent GC 6890 (3 of them) having intermittent and inconsistent error messages where the display on the GC will read «signal 1 buffer full error». This happens during the middle of runs sometimes a day after the system has been rebooted, sometimes it may be 2-3 weeks.
Any ideas…? We are running MSD Chemstation, Version D.02 00 275
We also have a problem where we’ll be in the middle of a run and all a sudden the Instrument Icon has disappeared and data that may have been running will be lost. The autosampler won’t continue after that, since we run purge and trap, but there is no rhyme or reason as to what is going on. Our software on our computers is XP.
-
- GasMan
-
- Posts: 582
- Joined: Mon Sep 13, 2004 8:22 pm
- Location: PA
by GasMan » Thu Sep 06, 2012 8:26 pm
I think that this could be a data transfer problem between the GC and the PC. The raw data is stored in temporary memory in the GC, the buffer, and the PC takes the data out of the buffer. If the PC cannot take the data out of the buffer fast enough due to a slow connection, you may see this problem, as the buffer will become full. I have only seen this problem when trying to control a GC remotely over the internet and my home connection was slow. By reducing the data rate collection at the GC, I was able to solve it.
From the other problems that you describe, I would get somebody to look at your internet setup. It could even be something like somebody else is trying to use the same I.P address.
Gasman
-
- antonk
-
- Posts: 318
- Joined: Mon Sep 13, 2010 8:28 am
by antonk » Fri Sep 07, 2012 11:57 am
when your GC has other detectors than MSD — they fill signal1 and signal2 buffer in GC.
GC chemstation reads these buffers — thus periodically exhausts them.
MSD chemtsation does not care.
Either turn off generic detector signal collection (from GC keyboard or in chemstation) or modify the method to read these detectors signal data.
-
- chloesabrina
-
- Posts: 59
- Joined: Thu Aug 02, 2007 3:19 pm
I only have one MSD attached to each GC and no other detectors.
I will have our IT person look at the IP addresses, the computers all store their data on the individual hard drives and not on a server. They also don’t all go down at the same time and they all vary when it will happen. Originally Agilent had said we still must have firewalls turned on, but that wasn’t the case.
This problem as been ongoing since we installed this software a few years ago we have another that is running under D 01.02.16 and it never has this problem.
-
- antonk
-
- Posts: 318
- Joined: Mon Sep 13, 2010 8:28 am
by antonk » Fri Sep 07, 2012 1:25 pm
There is virtual detector «Test plot».
Please see how signal1 and signal2 are configured (bound to detector).
[Signal 1] and [Signal 2] GC buttons.
-
- chloesabrina
-
- Posts: 59
- Joined: Thu Aug 02, 2007 3:19 pm
Hi Antonk,
What do you mean «see how the signals are configured»? I’m not sure what information you need or where to go on control panel. I see the test plot, but what information am I looking for?
-
- antonk
-
- Posts: 318
- Joined: Mon Sep 13, 2010 8:28 am
by antonk » Fri Sep 07, 2012 3:47 pm
The task is: Turn off data collection for Signal 1 and Signal 2.
Press the [Signal] [1] and examine — if it can be turned off.
Also have a look at your method. If there is no way to disable data collection for GC signals — it make sense to start data collection — and just ignore them.
IMO page 41 of
http://www.chem.agilent.com/Library/use … -90070.pdf
Enable GC signal collection and do not [_] store them.
Who is online
In total there are 0 users online :: 0 registered, 0 hidden and 0 guests (based on users active over the past 5 minutes)
Most users ever online was 1117 on Mon Jan 31, 2022 2:50 pm
Users browsing this forum: No registered users and 0 guests
Latest Blog Posts from Separation Science
Separation Science offers free learning from the experts covering methods, applications, webinars, eSeminars, videos, tutorials for users of liquid chromatography, gas chromatography, mass spectrometry, sample preparation and related analytical techniques.
Subscribe to our eNewsletter with daily, weekly or monthly updates: Food, Environmental, (Bio)Pharmaceutical, Bioclinical, Liquid Chromatography, Gas Chromatography and Mass Spectrometry.