We Keep Coding

Change Program Buffering Okuma OSP-300M

I'm currently running a small loop in g-code that has to wait for a common variable to change values. With Program Buffering ON, my g-code program does not see changes to the variables!
What is the best way to turn Program Buffering OFF while I am in this g-code loop?
If I manually set Program Buffering (NC Optional Parameter Bit No.2 Bit 7 to "DOES NOT". Then my loop behaves appropriately and the controller properly checks the value of the common variable each loop.
NLOOP G04 F1
IF[VC890 EQ 0] GOTO NRTS
GOTO NLOOP
NRTS RTS
Very straight forward loop. Maybe it needs to be more complex.
Perhaps if it was longer the buffer wouldn't matter?
I expect my customer's will want Program Buffering turned on.
Can I turn it off temporarily with the THINC API?
Because if it works, this would be great:
public void SetNCOptionalParameterBit(
int intBitIndex,
int intBitNo,
OnOffStateEnum enValue);
If this function will let me set param bit no 2 bit 7 on and off then this would probably be a valid work around.
Okuma.CMDATAPI.DataAPI.COptionalParameter myCOPtionalParameter;
myCOptionalParameter = new Okuma.CMDATAPI.DataAPI.COptionalParameter();
myCOPtionalParameter.SetNCOptionalParameterBit(2, 7,
Okuma.CMDATAPI.Enumerations.OnOffStateEnum.On);

What about M331 to prevent read ahead? (I won’t be at a control for a few days to verify usage, I’m holding my newborn and it’s 4am right now but I think it can go either on the line where you read variable on or the line before.)
NLOOP G04 F1 M331 (buffering prohibit)
IF[VC890 EQ 0] GOTO NRTS
GOTO NLOOP
NRTS RTS

The SetNCOptionalParameterBit() function is capable of setting NO. 2, BIT 7.
However, depending on what version of API you have, the THINC API test application might fail to do so. I confirmed there is a bug in the test app for API 1.17.2.0. And it was fixed by the time 1.18.0.0 was released.
So just be aware of that. Even if your machine has an older API such as 1.17.2.0, you should still be able to write code that uses this function successfully. Just ignore the test app results.

The best solution for my scenario was saving the current value of NC Optional Parameter 2 into a common variable, then changing it to Does Not buffer then running my code, then putting it back to whatever it was before.
in Gcode:
VC892 = VOPRB[2] (save current NC Optional Parameter bit 2 value)
VOPRB[2] = [VOPRB[2] OR 128] (bit magic to flip bit 7 to a 1 if its not)
(insert code to be run without buffering)
VOPRB[2] = VC892 (put back saved NC Optional Parameter bit 2 value)

windows phone accelerometer jitter

I would like to get accelerometer readings every 10ms from my Windows Phone 8, but instead I observe some jitter: the spacing between readings will be 8,10,12,9, or the like. So approximately 10, but not exactly.
I was wondering whether someone could suggest a way to get more reliable readings.
The core of my code looks like this:
var accelerometer = Windows.Devices.Sensors.Accelerometer.GetDefault();
accelerometer.ReadingChanged += accelerometer_ReadingChanged;
accelerometer.ReportInterval = 10;
The phone reports a MiminumReportingInterval of 10, so that should be fine. My callback just adds the numbers to a list, which I will send over the network at the end.
I am looking at the time in AccelerometerReadingChangedEventArgs.Timestamp, and that's where I see that the interval isn't always 10ms. Here's what the times looked like in the latest measurements: 105,118,128,134,146,157,163,177,187,198,208,213,232,238,245,255,263,279,285,295,303,313,324,334,345,355,363,375,385
So: is there something I can do to get more precisely spaced measurements? Or is this just the best this particular hardware can do?

There is a great article on Windows Phone Developer Blog which covers accelerometer in details.
One of the points of the article is that, yes, the stream of values can and most probably will be 'jittery' so you should implement some method of filtering. One such method is a low pass filter.
The smoother the data after filtering, the bigger the delay will be between the actual change and the reading. In other words, if you used accelerometer in a game as a 'steering wheel', a lot of filtering will result in late turning of a car, but no filtering will probably result in a jittery car. So, the best is to set it somewhere in between, depending on the use case.

Any pins on rs232 which can be used to detect voltage as input

Is there a way i can get a voltage input using rs232? What i am doing now is i have 2 pc hooked up to rs232 to communicate using gnd, tx and rx pin. Ive also connect DTR to a switch and when the switch is pressed im able to get a voltage output to drive a LED. What i want to do now is that when the led lights up, i will somehow get a input and change some stuffs in m programming. Is it possible to do that? Thanks in advance.
P.S. Im doing C# programming

Not directly. Your port RS323 communicates using digital signals that are always 5 volts. You need an analog-to-digital converter (ADC) between your voltage source and the RS232 port. Check out sparkfun.com for plenty of options.

Yes, there are several inputs. First of all which are inputs depends on if the RS232 is a DCE or DTE. Originally this standard was put together to connect a terminal to a modem. The DCE is the model and the DTE is the terminal. You wire the pins 1 to 1. Hence Tx can be a receiver or a transmitter.
A PC is typically a DTE. With that in mind this info may make more sense now: http://en.wikipedia.org/wiki/RS-232
The voltages are a nominal +- 7V. Actual a typical range of +-3V to +-15V. Be warned on a negative voltage is a logic 1.
As for C# you have access to all of the pins. Check out the class SerialPort.
Good luck
Rob

Yes it is possible. I did it.
Just connect the - (minus, ground) of the energy source to RS232 RX pin (Refer to anywhere in Internet to be sure where the RX pin is). When you give voltage (as pulse) to this pin, you see some meaningless actions in your port. There appears an OnComm event as 'Receive' but it has no start bit, no stop bit, it is fully meaningless. But any program which monitors RS232 (COM Ports) will show that something is happening on the port (Such as ' 00 ' in HEX or '[00]' in ascii).
As I said it has no start and stop bits, its voltage is not the average voltage needed for RS232 communication, so you must detect it with a subroutine like this (you can not handle it any other way):
Create a timer with 1ms.
timer1.enabled = false
----Don't forget to disable it
if mscomm1.inbuffercount > 0 then
-----put your code here
-----it means the voltage has appeared at RX
-----for example you can code 'buttonpresscount=buttonpresscount+1'
end if
waitfortheactionend:
if mscomm1.inbuffercount >0 then
----there is still some meaningless voltage
----wait until pulse ends, so
doevents
goto waitfortheactionstop
end if
----Don't forget to enable the timer again
timer1.enabled = true
I hope this will be helpfull.
Sedat K.

WPF dispatcher performance (100-200 updates/sec)

In a WPF Window, I've got a line chart that plots real-time data (Quinn-Curtis RealTime chart for WPF). In short, for each new value, I call a SetCurrentValue(x, y) method, and then the UpdateDraw() method to update the chart.
The data comes in via a TCP connection in another thread. Every new value that comes in causes an DataReceived event, and its handler should plot the value to the chart and then update it. Logically, I can't call UpdateDraw() directly, since my chart is in the UI thread which is not the same thread as where the data comes in.
So I call Dispatcher.Invoke( new Action (UpdateDraw()) ) - and this works fine, well, as long as I update max. 30 times/sec. When updating more often, the Dispatcher can't keep up and the chart updated slower than the data comes in. I tested this using a single-thread situation with simulated data and without the Dispatcher there are no problems.
So, my conclusion is that the Dispatcher is too slow for this situation. I actually need to update 100-200 times/sec!
Is there a way to put a turbo on the Dispatcher, or are there other ways to solve this? Any suggestions are welcome.

An option would be to use a shared queue to communicate the data.
Where the data comes on, you push the data to the end of the queue:
lock (sharedQueue)
{
sharedQueue.Enqueue(data);
}
On the UI thread, you find a way to read this data, e.g. using a timer:
var incomingData = new List<DataObject>();
lock (sharedQueue)
{
while (sharedQueue.Count > 0)
incomingData.Add(sharedQueue.Dequeue());
}
// Use the data in the incomingData list to plot.
The idea here is that you're not communicating that data is coming in. Because you have a constant stream of data, I suspect that's not a problem. I'm not saying that the exact implementation as give above is the rest, but this is about the general idea.
I'm not sure how you should check for new data, because I do not have enough insight into the details of the application; but this may be a start for you.

Youre requierments are bonkers- You seriously do NOT need 100-200 updates per second, especialyl as teh screen runs at 60 updates per second normally. People wont see them anyway.
Enter new data into a queue.
Trigger a pull event on / for the dispatcher.
Santize data in the queue (thro out doubles, last valid wins) and put them in.l
30 updates per second are enough - people wont see a difference. I had performacne issues on some financial data under high load with a T&S until I did that - now the graph looks better.
Keep Dispatcher moves as few as you can.

I still like to know why you'd want to update a chart 200 times per second when your monitor can't even display it that fast. (Remember, normal flatscreen monitors have an update-rate of 60 fps)
What's the use of updating something 200 times per second when you can only SEE updates 60 times per second ?
You might as well batch incoming data and update the chart at 60 fps since you won't be able to see the difference anyway.
If it's not just about displaying the data but you're doing something else with it - say you are monitoring it to see if it reaches a certain threshold - than I recommend splitting the system in 2 parts : one part monitoring at full speed, the other independently displaying at the maximum speed your monitor can handle : 60 fps.
So please, tell us why you want to update a ui-control more often than it can be displayed to the user.

WPF drawing occurs in a separate thread. Depending on your chart complexity, your PC must have had a mega-descent video card to keep up with 100 frames per second. WPF uses Direct3D to draw everything on screen and optimizing video driver for this has been added in Vista (improved in Windows 7). So, on XP you might have troubles just because of your high data-output rate on poorly designed OS.
Despite all that, I see no reason of printing information to screen with a rate of more than 30-60 frames per second. Come on! Even FPS shooters does not require such a strong reflexes from player. Do you want to tell me, that your poor chart does? :) If by this outputting, you produce some side-effects, which are what you actually need, then it's completely different story. Tell us more about the problem then.

Greater time resolution using .NET Micro Framework on Netduino board (for dimming an LED)?

I'm programming a Netduino board using the .NET Micro Framework 4.1 and want to get a higher time resolution than milliseconds. This is because I'm attempting to dim an LED by blinking it really fast.
The issue is that the sample code uses Thread.Sleep(..) which takes a number of milliseconds.
Sample code from http://netduino.com/projects/ showing the issue in question:
OutputPort ledOnboard = new OutputPort(Pins.ONBOARD_LED, false);
while (true)
{
ledOnboard.Write(true);
Thread.Sleep(1); // << PROBLEM: Can only get as low as 1 millisecond
Even if there's another way to accomplish dimming by not using a greater time resolution, I'm game.

This doesn't answer your question about getting a better time resolution, but it does solve your problem with changing the brightness on an LED. You should be using the PWM module for the Netduino.
Netduino Basics: Using Pulse Width Modulation (PWM) is a great article on how to use it.

I have had a similar problem in the past and used the following method to time in the microsecond range. The first line determines how many ticks are in a millisecond (its been a while since I used this, but I think 1 tick was 10 microseconds). The second line gets the amount of time the system has been on (in ticks). I hope this helps.
public const Int64 ticks_per_millisecond = System.TimeSpan.TicksPerMillisecond;
public static long GetCurrentTimeInTicks()
{
return Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
}

You can use a timer to raise an event instead of using sleep.
The Interval property on a timer is a double so you can have less than a millisecond on it.
http://msdn.microsoft.com/en-us/library/0tcs6ww8(v=VS.90).aspx

In his comment to Seidleroni's answer BrainSlugs83 suggests "sit in a busy loop and wait for the desired number of ticks to elapse. See the function I added in the edit". But I cannot see the function added to the edit. I assume it would be something like this:
using System;
using Microsoft.SPOT.Hardware;
private static long _TicksPerMicroSecond = TimeSpan.TicksPerMillisecond/1000;
private void Wait(long microseconds)
{
var then = Utility.GetMachineTime().Ticks;
var ticksToWait = microseconds * _TicksPerNanoSecond;
while (true)
{
var now = Utility.GetMachineTime().Ticks;
if ((now - then) > ticksToWait) break;
}
}

A point that you might not be thinking about is that your code is relying on the .NET System namespace, which is based on the real time clock in your PC. Notice that the answers rely on the timer in the device.
Moving forward, I would suggest that you take a moment to qualify the source of the information you are using in your code -- is it .NET proper (Which is fundamentally based on your PC), or the device the code is running on (Which will have a namespace other than System, for example)?
PWM is a good way to control DC current artificially (by varying the pulse width), but varying the PWM frequency will still be a function of time at the end of the day.
Rather than use delays....like Sleep....you might want to spawn a thread and have it manage the brightness. Using Sleep is still basically a straight line procedural method and your code will only be able to do this one thing if you use a single thread.