Big Demo (was: Re: Getting ready for the first release!)

M

Thread Starter

Mario de Sousa

Juan Carlos Orozco wrote:
>
> Mario,
>
> About the point 10 - big demo,
>
> I had serious difficulties running LinuxPLC in RedHat 7.0. I could not find
> the console-tools-dev equivalent. I tried the smm-mgr -g and I am getting a
> lot of "Error initializing the plc" messages. For now I gave up trying with
> RedHat 7.0 because debian seemed to work easier.
>
> With the Corel Linux 1.2 (slink debian) things worked better except for the
> vitrine that did not run.


We have to figure out why things are not working in these distributions... I guess this is a good reason to get a binary release out? It doesn't mean we shouldn't figure out what the problems are though...

The console-tools-dev package is only required for the mmi/kbd module. This module allows a user to use the keyboard as push buttons. This is mainly for testing without having to revert
to physical inputs... The rest of the PLC should work without this module. The demos use it, but I think a workaround is still available if this module is not compiled (Jiri, can you confirm this?).

> Since debian seemed to work better I decided to
> get the current stable version of debian (potato). Things worked beautifully
> with this linux, the demos worked very well. Except for the tcl demo that
> has a known bug in potato (I just could not figure out the workaround) when
> compiling /lang/tcl and running ./configure I get a message saying that int
> could not find tcl configuration definitions. Any way I am not planning to
> use tcl for the moment so this is not a problem for now.


I am attaching a file with an email I sent Greg explaining the same difficulties I experienced and how I got around them. Their seems to be a bug in the configure script. How it got there,
I don't know. Maybe people with experience using autoconf can help here?

> I finish installing debian potato yesterday so I am barely starting with the
> demo. I have some documents on the project and want to start trying some
> modifications on the basic demos, I will base my project on the basic_dsp
> demo since my project has some PIDs in it. By the way what is the graph part
> of the vitrine in the basic_dsp demo supposed to do? On my computer it just
> moves a couple of + to the right or to the left as I type 0-9. The two +
> signs move together. Taking a second look to the vitrine.conf I may have
> found the answer myself, it seems there is a typo, in the last line it
> should be out_1 instead of out_f32 for the x_plc_pt and y_plc_pt. One more
> thing, when exiting from the demo my terminal does not make a correct
> carriage return any more which makes it useless. I need to start a new
> terminal after exiting vitrine.

I'm sorry. I have to go now. I'll look into this later on. Anyway, this functionality of the vitrine is not quite finished. I was doing this to test the DSP module. I got stuck doing the
filters of the DSP module, and I have not yet found a book with examples with numbers to help me debug my filters. Anyway, lowpass and highpass seem to be working. Bandpass and bandreject are the problematic ones.


Thanks for your help Juan!

Keep up the good work!

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Juan Carlos Orozco

Mario,

I am making some progress with the big demo and I will probably post the first version sometime this week. How do I post my files for this demo? I
don't want for now to mess up with cvs uploads.

I am using a lot of constants for my program, I will write a module that writes all this constants (it only executes one time when the plc starts). This constants are all float values, in my design ideas I find recurrently the need to write float values to plc points, therefore I decided to write two new functions in the gmm.h and gmm.c. The conversion is based on your
typeconv function from the dsp module.

f32 plc_get_f32(plc_pt_t p)
{
u32 tmp_u32;

tmp_u32 = plc_get(p);

return (*((f32 *)&tmp_u32));
}

int plc_set_f32(plc_pt_t p, f32 val)
{
u32 tmp_u32;

tmp_u32 = (*((u32 *)&val));

return plc_set(p, tmp_u32);
}

I also wrote a module called extramath to implement the math operations that can not be done in the dsp module for now. The main problem is that I can not multiply two variables using the dsp module. The other problem is that I can not add a constant. The second one has a simple workaround, if I define a UNITY constant (1.0) then I use the variable multiplier in the add
function to set its value. For more complex math the dsp module is also lacking trigonometric, logarithmic and power functions.

I am having difficulties running two dsp modules (with different module names) concurrently. Therefore for now I am using just one dsp module. In fact I have two sample projects (very simple) that I don't know why they don't work. One uses two dsp modules and the other uses a variable from the Kbd module in the dsp module directly. In both cases I am getting a wrong magic message. What is magic means? Where is this magic value assigned?

There is a problem in the vitrine module. The numbers are printed with no fixed length so for example in integers (which is the worst case) if I write 10 and then 3 I will get a 30. The zero is never erased. For the purpose of my demo I did a quick and dirty arrangement to the vitrine.c program, in the snprintf functions I changed %f with %10.2f and %d with %10.2f. The problem with this is that it is not a generic solution, all floats are going to be displayed in a 10.2 format (10 digit 2 decimal) which is not acceptable in
many cases.

By the way the workaround for the tcl was not attached to your previous message.

Regards,

Juan Carlos Orozco

ACElab Industrial Automation
[email protected]
www.ace-lab.com


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Juan Carlos Orozco wrote:
>
> Mario,
>
> I am making some progress with the big demo and I will probably post the
> first version sometime this week. How do I post my files for this demo? I
> don't want for now to mess up with cvs uploads.

You can email me a tar.gz of the files you want posted, and I'll put them up for you. I'm sure Jiri or Curt wouldn't mind either.

> I am using a lot of constants for my program, I will write a module that
> writes all this constants (it only executes one time when the plc starts).

We should probably add another option to the the point configuration line in the configuration file allowing a user to define the initial value of a point.

Can anybody think of an acceptable syntax for the point configuration line? Or maybe we should use another table for initializing points?

Once we have the syntax nailed down, it shouldn't be too difficult to code it.

> This constants are all float values, in my design ideas I find recurrently
> the need to write float values to plc points, therefore I decided to write
> two new functions in the gmm.h and gmm.c. The conversion is based on your
> typeconv function from the dsp module.
>
> f32 plc_get_f32(plc_pt_t p)
> {
> u32 tmp_u32;
>
> tmp_u32 = plc_get(p);
>
> return (*((f32 *)&tmp_u32));
> }
>
> int plc_set_f32(plc_pt_t p, f32 val)
> {
> u32 tmp_u32;
>
> tmp_u32 = (*((u32 *)&val));
>
> return plc_set(p, tmp_u32);
> }


Good idea! These functions should probably be inlined. Unfortunately we can't safely add them to the gmm.h file. Jiri, do you have any
sugestions? It also seems a pity that we need to create a new f32 varible, and then access it through a pointer to do what is essentialy a byte for byte copy. Is the compiler intelligent enough to optimise all this?

> I also wrote a module called extramath to implement the math operations that
> can not be done in the dsp module for now. The main problem is that I can
> not multiply two variables using the dsp module. The other problem is that I
> can not add a constant. The second one has a simple workaround, if I define
> a UNITY constant (1.0) then I use the variable multiplier in the add
> function to set its value. For more complex math the dsp module is also
> lacking trigonometric, logarithmic and power functions.
>

Yes! I left the easy stuff out, but it is probably what is most required. I'll try and add these functions next week. Let me finish the
timer_util.c functions, and then the period library, and then I'll tackle whatever you come up with.


> I am having difficulties running two dsp modules (with different module
> names) concurrently. Therefore for now I am using just one dsp module. In
> fact I have two sample projects (very simple) that I don't know why they
> don't work. One uses two dsp modules and the other uses a variable from the
> Kbd module in the dsp module directly. In both cases I am getting a wrong
> magic message. What is magic means? Where is this magic value assigned?

The structure used to store a plc_pt has a member variable where we store a magic value. It is a way of plc_get() and plc_set() of making sure
that they get a valid plc_pt handed over to them. It seems that an invalid plc_pt is being used.

There is either an error in the configuration file (have you looked in the log file to see if any warnings are being spit out?), or a bug in
the DSP module. It could be something else that seems hardly related. If you have no warnings in the log file, could you email me the configuration
files so I can try and replicate the error and track it down?

> There is a problem in the vitrine module. The numbers are printed with no
> fixed length so for example in integers (which is the worst case) if I write
> 10 and then 3 I will get a 30. The zero is never erased. For the purpose of
> my demo I did a quick and dirty arrangement to the vitrine.c program, in the
> snprintf functions I changed %f with %10.2f and %d with %10.2f. The problem
> with this is that it is not a generic solution, all floats are going to be
> displayed in a 10.2 format (10 digit 2 decimal) which is not acceptable in
> many cases.

Yes... :-( The vitrine was started before multi-bit points were suported by the plc. I started adding support for multi-bit points to the
vitrine, but stopped when I put off the debugging of the DSP filter functions.
It is probably time to finish it.

What would you rather have me do first?
a) initialising plc points from the config file,
b) dsp blocks for multiplying, logarithm, powers, etc...
c) support for multi-bit points in the vitrine

Maybe other people would like to help in getting these done?

> By the way the workaround for the tcl was not attached to your previous
> message.

I'll email you directly for this. I have delayed long enough with this answer as it is...

By the way, what time-zone do you live on? I'm on GMT+0.

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Juan Carlos Orozco

Mario de Sousa wrote:
>
> Juan Carlos Orozco wrote:
> >
> > Mario,
> >
> > I am making some progress with the big demo and I will probably post the
> > first version sometime this week. How do I post my files for
> this demo? I
> > don't want for now to mess up with cvs uploads.
>
> You can email me a tar.gz of the files you want posted, and I'll put
> them
> up for you. I'm sure Jiri or Curt wouldn't mind either.
>

I already sent Mario the first (partial) version of the big demo. It should be in the linuxplc cvs soon.

> > I am using a lot of constants for my program, I will write a module that
> > writes all this constants (it only executes one time when the
> plc starts).
>
> We should probably add another option to the the point configuration
> line
> in the configuration file allowing a user to define the initial value of
> a point.
>
> Can anybody think of an acceptable syntax for the point configuration
> line? Or maybe we should use another table for initializing points?
>

Using an extra parameter on the point configuration sounds like a better solution. Maybe

point name "large name" Module at xx [default xxx]
or point name "large name" Module at xx [init xxx]
It should be an optional parameter, if its not there the point will default to 0.
One more thing, the point declaration has no data type except for the distinction of single-bit and multi-bit points, therefore we have to interpret the number from its format.

init (true|false)
init [+|-](x)+
init [+|-](x)+.(x)+[(e|E)[+|-](x)+]
Where x is a digit and (x)+ is one or more digits.

> Once we have the syntax nailed down, it shouldn't be too difficult to
> code
> it.
>
> > This constants are all float values, in my design ideas I find
> recurrently
> > the need to write float values to plc points, therefore I
> decided to write
> > two new functions in the gmm.h and gmm.c. The conversion is
> based on your
> > typeconv function from the dsp module.
> >
> > f32 plc_get_f32(plc_pt_t p)
> > {
> > u32 tmp_u32;
> >
> > tmp_u32 = plc_get(p);
> >
> > return (*((f32 *)&tmp_u32));
> > }
> >
> > int plc_set_f32(plc_pt_t p, f32 val)
> > {
> > u32 tmp_u32;
> >
> > tmp_u32 = (*((u32 *)&val));
> >
> > return plc_set(p, tmp_u32);
> > }
>
> Good idea! These functions should probably be inlined. Unfortunately
> we can't safely add them to the gmm.h file. Jiri, do you have any
> sugestions? It also seems a pity that we need to create a new f32
> varible,
> and then access it through a pointer to do what is essentialy a byte for
> byte copy. Is the compiler intelligent enough to optimise all this?
>

The functions where included in the demo in a file called lib1.c . Therefore the demo is ready to execute with a make and ./demo commands from its directory. The program is a little bit messy because we need some more functions in the dsp module, but it is functional. Feedback on this project is welcome.

> > I also wrote a module called extramath to implement the math
> operations that
> > can not be done in the dsp module for now. The main problem is
> that I can
> > not multiply two variables using the dsp module. The other
> problem is that I
> > can not add a constant. The second one has a simple workaround,
> if I define
> > a UNITY constant (1.0) then I use the variable multiplier in the add
> > function to set its value. For more complex math the dsp module is also
> > lacking trigonometric, logarithmic and power functions.
>
> Yes! I left the easy stuff out, but it is probably what is most
> required.
> I'll try and add these functions next week. Let me finish the
> timer_util.c
> functions, and then the period library, and then I'll tackle whatever
> you
> come up with.
>
> > I am having difficulties running two dsp modules (with different module
> > names) concurrently. Therefore for now I am using just one dsp
> module. In
> > fact I have two sample projects (very simple) that I don't know why they
> > don't work. One uses two dsp modules and the other uses a
> variable from the
> > Kbd module in the dsp module directly. In both cases I am
> getting a wrong
> > magic message. What is magic means? Where is this magic value assigned?
>
> The structure used to store a plc_pt has a member variable where we
> store
> a magic value. It is a way of plc_get() and plc_set() of making sure
> that
> they get a valid plc_pt handed over to them. It seems that an invalid
> plc_pt is being used.
>
> There is either an error in the configuration file (have you looked in
> the log file to see if any warnings are being spit out?), or a bug in
> the
> DSP module. It could be something else that seems hardly related. If you
> have no warnings in the log file, could you email me the configuration
> files
> so I can try and replicate the error and track it down?
>
> > There is a problem in the vitrine module. The numbers are
> printed with no
> > fixed length so for example in integers (which is the worst
> case) if I write
> > 10 and then 3 I will get a 30. The zero is never erased. For
> the purpose of
> > my demo I did a quick and dirty arrangement to the vitrine.c
> program, in the
> > snprintf functions I changed %f with %10.2f and %d with %10.2f.
> The problem
> > with this is that it is not a generic solution, all floats are
> going to be
> > displayed in a 10.2 format (10 digit 2 decimal) which is not
> acceptable in
> > many cases.
>
> Yes... :-( The vitrine was started before multi-bit points were
> suported
> by the plc. I started adding support for multi-bit points to the
> vitrine,
> but stopped when I put off the debugging of the DSP filter functions.
> It is probably time to finish it.

For now I will use vitrine in the demo to be able to concentrate on the control issues. After the control part of the whole demo is ready, I will
start thinking of making a graphical user interface for it.

> What would you rather have me do first?
> a) initialising plc points from the config file,
> b) dsp blocks for multiplying, logarithm, powers, etc...
> c) support for multi-bit points in the vitrine
>

The order in which you wrote them seems to me to be the correct one.


Regards,

Juan Carlos Orozco

ACElab Industrial Automation
[email protected]
www.ace-lab.com
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Juan Carlos Orozco wrote:
>
> I already sent Mario the first (partial) version of the big demo. It should
> be in the linuxplc cvs soon.

It's in there now.

I just ran ./demo and it looks very interesting. Good work! I haven't yet had time to figure out how it works. I thought it would be better
not to delay putting it up in the cvs any further. I was off-line yesterday (National Holiday in Portugal).

Dan, do you think you could get Juan a cvs login? It seems I mis-understood him, and he really does prefer to upload directly to the
cvs...

(I'll answer the rest in subsequent messages...)


Cheers,

Mario.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Juan Carlos Orozco:
> > f32 plc_get_f32(plc_pt_t p)
...
> > int plc_set_f32(plc_pt_t p, f32 val)
...

Mario:
> Good idea! These functions should probably be inlined. Unfortunately we
> can't safely add them to the gmm.h file.

What's the problem with adding them to the gmm.h file? They don't use any internal stuff...

> It also seems a pity that we need to create a new f32 varible, and then
> access it through a pointer to do what is essentialy a byte for byte
> copy. Is the compiler intelligent enough to optimise all this?

It probably is intelligent enough, but we can eliminate the temporary variable altogether and then there won't be anything to optimize; it'll be
just a typecast: return plc_set(p, *(u32 *)&val);

Much the same can be done for plc_get_f32() only weirder - we'll have to typecast plc_get as a function pointer.

> > In both cases I am getting a wrong magic message. What is magic means?
> > Where is this magic value assigned?

> The structure used to store a plc_pt has a member variable where we store
> a magic value. It is a way of plc_get() and plc_set() of making sure that
> they get a valid plc_pt handed over to them. It seems that an invalid
> plc_pt is being used.

Other structures have magic values too - again, it's just to make sure that the thing is valid.

If there's wrong magic, it can mean:
- that's not a plc_pt you're passing,
- it's not initialized, or
- it's corrupted somehow (eg buffer overrun)

> If you have no warnings in the log file, could you email me the
> configuration files so I can try and replicate the error and track it
> down?

If you feel like tracing it down yourself, run it in the debugger and make sure that valid and opaque[0] stay the same once the point is initialized (should be 7 and hex F1, or the other way around).

Jiri
--
Jiri Baum <[email protected]>
"In my opinion, the GPL is optimized to build a strong software community at the expense of a strong commercial software business model."
--Craig Mundie, Senior VP, Microsoft; 17 May 2001

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Jiri Baum wrote:
>
> Juan Carlos Orozco:
> > > f32 plc_get_f32(plc_pt_t p)
> ...
> > > int plc_set_f32(plc_pt_t p, f32 val)
> ...
>
> Mario:
> > Good idea! These functions should probably be inlined. Unfortunately we
> > can't safely add them to the gmm.h file.
>
> What's the problem with adding them to the gmm.h file? They don't use any
> internal stuff...

Inlined functions can not be compiled more than once.

Say you are generating an executable
testplc

and have two c files:
testplc.c
testutil.c

Both *.c files have #include "plc.h".

What you would want to do is:
gcc -c testplc.c
gcc -c testutil.c
gcc -o testplc testplc.o testutil.o (...)

What happens when you compile is that you get the inlined functions in both testplc.o _and_ testutil.o functions, therefore getting an error when you try to link them.

Please correct me if I am missing something here!

> > It also seems a pity that we need to create a new f32 varible, and then
> > access it through a pointer to do what is essentialy a byte for byte
> > copy. Is the compiler intelligent enough to optimise all this?
>
> It probably is intelligent enough, but we can eliminate the temporary
> variable altogether and then there won't be anything to optimize; it'll be
> just a typecast: return plc_set(p, *(u32 *)&val);

Yes, it's what I did... ;-)

> Much the same can be done for plc_get_f32() only weirder - we'll have to
> typecast plc_get as a function pointer.

Unfortunately, this won't work. The compiler doesn't buy it!

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri:
> > What's the problem with adding them to the gmm.h file? They don't use
> > any internal stuff...

Mario:
> Inlined functions can not be compiled more than once.
...
> What happens when you compile is that you get the inlined functions in
> both testplc.o _and_ testutil.o functions, therefore getting an error
> when you try to link them.

I thought you only get an error if there's two different functions with the same name, but I'd have to check to be sure.

> > It probably is intelligent enough, but we can eliminate the temporary
> > variable altogether and then there won't be anything to optimize; it'll
> > be just a typecast: return plc_set(p, *(u32 *)&val);

> Yes, it's what I did... ;-)

> > Much the same can be done for plc_get_f32() only weirder - we'll have
> > to typecast plc_get as a function pointer.

> Unfortunately, this won't work. The compiler doesn't buy it!

Then you haven't done it weird enough...

You need to typecast plc_get before you call it.

Presumably you'd be typecasting it to (f32 (*foo)(plc_pt_t)) or something... I have a friend who knows this stuff, I think I better go ask.

Jiri
--
Jiri Baum <[email protected]>
"In my opinion, the GPL is optimized to build a strong software community at the expense of a strong commercial software business model."
--Craig Mundie, Senior VP, Microsoft; 17 May 2001

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri:
> > > Much the same can be done for plc_get_f32() only weirder - we'll have
> > > to typecast plc_get as a function pointer.

Mario:
> > Unfortunately, this won't work. The compiler doesn't buy it!

Jiri:
> Then you haven't done it weird enough...
...
> I have a friend who knows this stuff, I think I better go ask.

Ok, according to Sarah, you can do it the simple way:
typedef f32 (*plc_get_f_func_t)(plc_pt_t p);
return ((plc_get_f_func_t) plc_get)(p);

or the difficult way:
return ( (f32(*)(plc_pt_t))plc_get )(p);


I prefer the second one, because the first is not all that simpler and the second at least looks neat :)


Jiri
--
Jiri Baum <[email protected]>
"In my opinion, the GPL is optimized to build a strong software community at the expense of a strong commercial software business model."
--Craig Mundie, Senior VP, Microsoft; 17 May 2001

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
n Sun, 17 Jun 2001 00:28:15 Jiri Baum wrote:

> Ok, according to Sarah, you can do it the simple way:
> typedef f32 (*plc_get_f_func_t)(plc_pt_t p);
> return ((plc_get_f_func_t) plc_get)(p);
>
> or the difficult way:
> return ( (f32(*)(plc_pt_t))plc_get )(p);
>
>
> I prefer the second one, because the first is not all that simpler and
> the second at least looks neat :)
>

I've kinda lost track of what this thread is trying to accomplish. It seems like we are going off on a tangent to save literaly a couple cycles, and in the end creating something that is not easy to understand. If you really care that much about a couple cycles, then you should be programming in assembly language not C (imho).

Why wouldn't you make the normal plc_get() just return a union type.

typedef union
{
unsigned char v_8;
unsigned short v_16;
unsigned long v_32;
float v_f;
} ANY_TYPE;

ANY_TYPE x;

ANY_TYPE plc_get (void)
{
return x;
}

int main (void)
{
ANY_TYPE y;

x.v_32 = 100;
y = plc_get();
printf ("%u %u %u\n", y.v_8, y.v_16, y.v_32);

x.v_f = 33.5;
y = plc_get();
printf ("%f\n", y.v_f);

return 0;
}


If this isn't the real problem, could somebody restate the problem.

Thanks
Gary James
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top