Support for a device (with DLL's) which is controlled by winforms(c++)

[Cetin Aslantepe]

Dear Supporter,

I have been trying to control a stepper motor via GUI(WinForms) with my little programming knowledge.

With the example programs of device, I get commands (movements) performed.

I was told that only by applying threads two main programs (device and winforms) is possible. Are threads necessary?

If yes, how should I design the program with threads best?
Are there other solutions?

I would be very happy about a feedback. Thanks in advance.

I appreciate your help.

With best regards
Cetin Aslantepe

[Richard Damon]

Threads makes it possible to do some things you couldn't do easily
otherwise.

Without threads, it be comes hard to keep your GUI running while you are
moving the motor, at least if you want the motor running somewhat fast
and smoothly, if you program is doing the actual motor control (i.e.
geerating each individual step operations).

This actually can even be a bit tricky to do with a non-real-time OS, as
the step timing needs to be tightly controlled, which an OS like windows
doesn't provide easily.

With Threads, you have one high priority 'real time' thread that is in
charge of the motor movement, with delay times of the order of the step
time of the motor, and a second GUI thread that runs your GUI and sends
operation commands to the motor thread.

[Cetin Aslantepe]

Dear Mr. Damon,

Thank you for your message,

I am not a C ++ expert. Would you please tell me the procedure very shortly.
Do I need classes for threads?
What should be considered?
Which project should I best create?
How should I link the two main programs with a Direction or represent in threads?
Many Thanks!
--------------------------------------------------------------------------------------------------------------------------------------
#include "MyForm.h"
using namespace Project2;

int UIMain()
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault;

MyForm^ NewUI = gcnew MyForm();
Application::Run(NewUI);

return 1;
}
----------------------------------------------------------------------------------------------------------------------------------
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#if defined(__APPLE__) && !defined(NOFRAMEWORK)
#include <libximc/ximc.h>
#else
#include <ximc.h>
#endif

// This line includes a c-profile for the "8MT173-25" stage
#include "8MT173-25.h"

int main (int argc, char* argv[])
{
/*
Variables declaration.
device_t, status_t, engine_settings_t, status_calb and calibration_t are types provided by the libximc library.
*/
device_t device;
result_t result;
int names_count;
char device_name[256];
const int probe_flags = ENUMERATE_PROBE;
const char* enumerate_hints = "";
char ximc_version_str[32];
device_enumeration_t devenum;

// unused variables
(void)argc;
(void)argv;

printf( "This is a ximc test program.\n" );
// ximc_version returns library version string.
ximc_version( ximc_version_str );
printf( "libximc version %s\n", ximc_version_str );

// Device enumeration function. Returns an opaque pointer to device enumeration data.
devenum = enumerate_devices( probe_flags, enumerate_hints );

// Gets device count from device enumeration data
names_count = get_device_count( devenum );

// Terminate if there are no connected devices
if (names_count <= 0)
{
printf( "No devices found\n" );
// Free memory used by device enumeration data
free_enumerate_devices( devenum );
return 1;
}

// Copy first found device name into a string
strcpy( device_name, get_device_name( devenum, 0 ) );
// Free memory used by device enumeration data
free_enumerate_devices( devenum );

printf( "Opening device...");
// Open device by device name
device = open_device( device_name );
printf( "done.\n" );

// Load c-profile
printf( "Setting profile for 8MT173-25... ");
result = set_profile_8MT173_25(device);
printf( "done. Result = %d\n", result );

//user_value = A * (step + mstep / pow(2, MicrostepMode - 1))-- the conversion to user units
//step = (int)(user_value / A) -- conversion from custom units
//mstep = (user_value / A - step) * pow(2, MicrostepMode - 1)
//Range: 1..65535.
//Position bzw. get_position
//speed -> z.b. SlowHome speed used for second motion (full steps) Range 0-100000
// if else-Schleife
//while schleife-- dow while schleife



printf( "Closing device..." );
// Close specified device
close_device( &device );
printf( "done.\n" );

return 0;
}

Thank you?

[Cetin Aslantepe]

Dear Supporter,

Is there perhaps sample programs, which two major programs communicate with the (GUI and device (with DLL)).
I am aware, it is a comprehensive question.
For some, this is certainly no challenge. It would be a great help for me.
About examples I would also very happy.

Thank you!

best regards
Cetin

[Keith Thompson]

You posted in comp.lang.c. You want comp.lang c++ -- probably.

Google Groups has a rather horrid bug that quietly drops the "++" from
the newsgroup name.

I've cross-posted this to comp.lang.c++ and redirected follows there.
If you reply to this message (and not to any others in this thread), you
should be able to continue the discussion in the correct newsgroup.

(I see you're using a lot of C library functions, which is valid, but
perhaps not a good idea if you want to program in C++.)

This syntax:

MyForm^ NewUI = gcnew MyForm();

suggests that you're using some non-standard dialect. Someone in
comp.lang.c++ who recognizes it might suggest a better place to post.

Previous message follows (I normally wouldn't top-post, but I made an
exception in this case):

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Kaz Kylheku]

On 2021-04-28, Cetin Aslantepe <cetin.asl...@gmail.com> wrote:
> Dear Supporter,
>
> I have been trying to control a stepper motor via GUI(WinForms) with
> my little programming knowledge.

Little programming knowledge + threads = bad mix.

> With the example programs of device, I get commands (movements)
> performed.
>
> I was told that only by applying threads two main programs (device and
> winforms) is possible. Are threads necessary?

Threads are almost never necessary; anyone who insists you need threads
to control a stepper motor with a GUI is incompetent.

You already have three independent actors in the mix: the computer,
the GUI user and the stepper motor.

Throwing more concurrency into the situation than that won't achieve
anything.

> If yes, how should I design the program with threads best?

Correct use of threads requires considerable expertise in concurrent
programming. Acquiring concurrent programming expertise requires a very
solid background in sequential programming.

There is already concurrency inherent in the control of a motor,
because a motor doesn't instantly react to the step commands. Your
progrm has to take that into account.

> Are there other solutions?

The details depend on what kind of API do you have available for
controlling the stepper motor?

I'm imagining you have some buttons on the GUI to step the motor. Is it
acceptable for your GUI to block (i.e. become unresponsive) when the
clicks a button, until the motor has finished stepping?

Is the underlying API blocking or asynchronous: is there a function
to step the motor which returns when the motor has finished stepping, or
is there a function which returns instantly, and another function for
monitoring whether the motor is done? Is it possible to get a
notification when the motor is done (e.g. callback function or some
other event)? Failing that, a timer could fake this out. If we know that
the motor can step in 50 milliseconds, we can set a 60 millisecond
timer. When the timer goes off, it will post an event into the GUI event
loop and we interpret that event as that the motor has finished
stepping.

If you can start the motor and get a notification when it's done, the
notification can be posted as an event into the GUI event loop. In that
case, the GUI can remain responsive at all times, and take various
strategies to deal with the motor. For instance, until it receives the
completion event from the motor API, it can disable the buttons (gray
them out).

Another possibility is to maintain a command queue. The buttons do not
send commands directly to the motor, but put them into a queue
maintained by the GUI. Whenever a command is put into the queue and the
motor is not busy, the oldest command is removed from the queue and
given to the motor. The motor is then marked busy to prevent further
commands from being sent. Whenever an event arrives indicating that the
motor has finished stepping, the GUI's event handler for the motor takes
the next event from the queue and sends it to the motor. If it finds
the queue empty, though, it clears the busy flag.

None of this requires threads. Threads could be there "under the hood":
for instance, the motor API might be using threads internally. Or if a
timer is used, the timer could be based on a thread. Those things are
encapsulated from us; we don't directly interact with their internals.
All of our logic is in a single thread centered around a GUI event loop.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[Cetin Aslantepe]

Dear Kaz,

Thank you for the extensive support. I really appreciated your support.

In the stepper motor is already all functions are stored under a DLL.
You are very right with your considerations, but I am not ready yet.
If I understand correctly, threads are not necessary for this problem???

First of all, I would like to use the GUI (WinForms) to make the first simple movements.
How should I proceed?

After first "easy" steps,I would improve my code.

Are there any example programs?

Best Regards
Cetin Aslantepe

[Cetin Aslantepe]

Dear Supporter,

First of all, I want my GUI to communicate with the stepper motor?
How would I do that?

Tahnk you !

best regards
Cetin

[Chris M. Thomasson]

It basically depends on if the motor api is blocking or not. Its been a
while since I did any GUI work, but I remember to never call a blocking
operation in the event loop.

[Kaz Kylheku]

On 2021-04-28, Cetin Aslantepe <cetin.asl...@gmail.com> wrote:

> Dear Kaz,
>
> Thank you for the extensive support. I really appreciated your support.
>
> In the stepper motor is already all functions are stored under a DLL.
> You are very right with your considerations, but I am not ready yet.
> If I understand correctly, threads are not necessary for this problem???

Threads are necessary only in problems where it is important to

1. Be able to instantly preempt any existing computation to switch to
a more important, higher priority task, for an indefinite period
of time.

2. Share a single processor among multiple users, at the same time,
without those users having to wait for their turn to use the machine.

3. Take advantage of multiple processors.

Regarding (1), interrupts can be used to preempt an existing computation
to do something important. Interrupts have to be handled quickly so
control is returned to the non-interrupt-time processing.

Regarding (3), threads are only necessary "under the hood": there are
ways to do parallel computing in higher level languages without any
programmer-visible threads.

> First of all, I would like to use the GUI (WinForms) to make the first simple movements.
> How should I proceed?

How about making the UI with the stepper motor functionality stubbed
out. Have all the elements in place with handlers for everything, like
any button clicks and whatever.

Are there code samples for the stepper motor DLL? Study them.

Someone who understands object-oriented programming would design a class
which controls the step motor. A dummy version of that class could be
implemented which simulates the step motor.

The GUI could be built around that, and then the dummy class can be
replaced with a drop-in compatible real implementation.

[Cetin Aslantepe]

Kaz Kylheku schrieb am Donnerstag, 29. April 2021 um 01:48:12 UTC+2:
> On 2021-04-28, Cetin Aslantepe <cetin.asl...@gmail.com> wrote:
Dear Kaz,
Thank you for the extensive support. I really appreciated your support.

> Threads are necessary only in problems where it is important to

> 1. Be able to instantly preempt any existing computation to switch to
> a more important, higher priority task, for an indefinite period
> of time.
>
> 2. Share a single processor among multiple users, at the same time,
> without those users having to wait for their turn to use the machine.
>
> 3. Take advantage of multiple processors.
>
> Regarding (1), interrupts can be used to preempt an existing computation
> to do something important. Interrupts have to be handled quickly so
> control is returned to the non-interrupt-time processing.

It is a small stepper motor, this is only used by one user.
Do you have example for this?

> How about making the UI with the stepper motor functionality stubbed
> out. Have all the elements in place with handlers for everything, like
> any button clicks and whatever.
>

What you mean with stubbed out?

> Are there code samples for the stepper motor DLL? Study them.

Yes, there are functions (commands for movments) for the Stepper motor DLL.

> Someone who understands object-oriented programming would design a class
> which controls the step motor. A dummy version of that class could be
> implemented which simulates the step motor.

Should this Class works by multithreading?

I honestly have no idea how to successfully complete this project.
Do you have any examples?

[David Brown]

On 29/04/2021 14:23, Cetin Aslantepe wrote:

> I honestly have no idea how to successfully complete this project.
> Do you have any examples?
>

It seems clear that you are very much out of your depth here. Is this a
homework or school project, a hobby project, or something for work?
(The best way forward depends on this.)

[James Kuyper]

On 4/29/21 8:23 AM, Cetin Aslantepe wrote:
> Kaz Kylheku schrieb am Donnerstag, 29. April 2021 um 01:48:12 UTC+2:

...

>> How about making the UI with the stepper motor functionality stubbed
>> out. Have all the elements in place with handlers for everything, like
>> any button clicks and whatever.
>>
> What you mean with stubbed out?

A stub function is function that does NOT do what the real function is
supposed to do - it's created simply for testing, to maker sure that the
calling function has something to call. In it's simplest form a stub
function does nothing at all except return an appropriate value. More
sophisticated stub functions will log the fact that they were called,
and maybe even information about the arguments that they were called
with, which can be useful for debugging.
A really sophisticated stub might even emulate doing what the real
function is supposed to do.

If you are currently accessing the stepper motor though some library
functions, one way to implement stubs would be to create a stub
alternative to that library. Link to the alternative library while
testing the user interface; don't link to the real library until you
know that the user interface is working.

> I honestly have no idea how to successfully complete this project.

>> Are there code samples for the stepper motor DLL? Study them.
> Yes, there are functions (commands for movments) for the Stepper motor
DLL.

He's not talking about commands for movements for the stepper motor,
he's talking about example code which calls those functions, to help you
understand how they're supposed to be used.

> I honestly have no idea how to successfully complete this project.

If you have no idea, you should consider the possibility it's the wrong
project for you, or that you're the wrong person for this project.

[Cetin Aslantepe]

> If you have no idea, you should consider the possibility it's the wrong
> project for you, or that you're the wrong person for this project.

Thank you for your support.