Hi guys,

I have just uploaded to the cvs a module to interact with cif cards.

I tested it with the card Hilscher was kind enough to lend me, and OMRON Devicenet digital I/O.

I have also uploaded a demo for anybody who happens to have these cards.


********************

Although we are still far from having a working IEC compiler, I feel we should make a release of the plc as it is.

What I would like to see before making a release:
1 - a tcl demo. This already exists in the demo/basic directory,
just needs re-organizing into an independent basic_tcl directory.
2 - get the modbus modules to compile, i.e. include the function
that was in the old io.c file into the modbus source files.
3 - a modbus demo explaining how to configure the module.
4 - Debug the filtering blocks of the dsp module.
5 - have the dio48 module use the new generic io library
6 - a demo directory for the dio48 module
7 - A user manual, probably in html format.
8 - a demo directory for the il compiler (e.g. implement the chaser
in il).
9 - A top level makefile that will make each module, and install
the libraries and executables into apropriate directories,
i.e. get all the executables into a single directory (probably
with sub-directories for io moduls, logic modules, utilities, ...)
10 - A big demo, with some nice graphics, and realistic processes...

Is anybody willing to help out with any of the above?


It may seem like a lot, but actually most should not take too long.


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

 

I'm in for the DIO48 stuff at least.
More as time permits.

Regards

cww


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

 

For the big demo it would be nice to have the LinuxPLC HMI from Greg Goodman.
(Just an idea).

Juan Carlos


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

 

Let me rephrase my previous message, I will be interested to help with the big demo, but I will like to know if there is any possibility of using the announced LinuxPLC HMI or do I have to do the graphical part from scratch?

The application that I have in mind is a textile printing machine including unwinder, printer, oven and winder. The actuators will be variable speed motors for the transmission, valves, heating devices, etc. the sensors will be speed feedback, power feedback from the motor drives, tension control sensors, temperature sensors, pressure sensors, level sensor for the printer, edge detectors for the alignment in the winder. Does this sound like something interesting?

Juan Carlos Orozco

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


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

 

> I'm in for the DIO48 stuff at least.
> More as time permits.

Hi Curt,

Actually, I've been glancing through the source of the DIO48 module, and it seems the functionality is almost identical to the parallel port module.

I'd probably leave this for later. I expect to grab some code from each of the above modules and produce a new DIO48 module with support for
multi-bit points, and with the ability to directly access the 8255 chip without going through the kernel module (i.e. the device
driver). I'll prbably change the device driver in the process too. At the moment I haven't quite figured out why it uses a separate /dev/xxx file
for _each_ _byte_ of the 8255. Why not a single 3 byte file, like I used for the parallel port kernel module?

May I sugest you concentrate on the user documentation for the moment?
Is this OK with you? Of course, if you prefer to go ahead with the DIO48 module, please be my guest!


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

 

Hi Mario

If you get there before I do, go ahead. I am, as I have been threatening, going to do a usability study to illuminate and help document what it's
like for some one to acquire, compile the code base and run the demos. Ask the dumb questions, etc. If I survive that, I am going to do the same
for adding an IO type. We need these HOWTO's and I have the advantage of distance and perspective along with a flameproof hide and an uncrushable ego.


Mario de Sousa wrote:

> Hi Curt,
>
> Actually, I've been glancing through the source of the DIO48 module,
> and it seems the functionality is almost identical to the parallel port
> module.
>
> I'd probably leave this for later. I expect to grab some code from each
> of the above modules and produce a new DIO48 module with support for
> multi-bit points, and with the ability to directly access the 8255
> chip without going through the kernel module (i.e. the device
> driver). I'll prbably change the device driver in the process too.

Without getting into my second flame war of the morning, why would we want to throw away the traditional UNIX model and access the card from
userland? Can an ioctl answer that need? And, if we must, can we do it in a manner compatible with RTLinux? Some of these cards support hardware
interrupts and it's an iffy thing to get these to userland.. Might be important for an "interrupt on change" mode.

> At the
> moment I haven't quite figured out why it uses a separate /dev/xxx file
> for _each_ _byte_ of the 8255. Why not a single 3 byte file, like I used
> for the parallel port kernel module?

I think there may be a reason. When I try to load the module, the autoprobe fails if the pins are loaded. There may be some blocking issues on open or some such. I haven't tried multiple opens on a single device yet either. It is interesting though, might be worth a email to the author. I had to hack some of the past versions but, this one I'm using right out of the box except to overide the autoprobe.

> May I sugest you concentrate on the user documentation for the moment?
> Is this OK with you? Of course, if you prefer to go ahead with the DIO48
> module, please be my guest!

Very diplomatic:^) It really is about the same thing as I have to dig in before I can write intelligent documentation.

Regards

cww


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