Visions of what will be.

Any specific plans Peter?


I rolled my own "PLC" (for home automation) with a Raspberry Pi Zero W written from scratch in Pascal - including an embedded webserver as "HMI" written in HTML (also from scratch).
Next up i've bought some ATSAMD ARM Cortex-M0 chips and RS422 IC's im going to try to learn next, but that would have to be in C/C++ (not as nice as Pascal sadly).

ojz0r said:

Any specific plans Peter?


I rolled my own "PLC" (for home automation) with a Raspberry Pi Zero W written from scratch in Pascal - including an embedded webserver as "HMI" written in HTML (also from scratch).
Next up i've bought some ATSAMD ARM Cortex-M0 chips and RS422 IC's im going to try to learn next, but that would have to be in C/C++ (not as nice as Pascal sadly).

Click to expand...

for me, language/syntax is irrelevant (they are all ugly, except ladder, of course ); libraries are what make the language choice for me.

Mara said:

Is this something similar to this?

https://www.beckhoff.com/english.asp?twincat/twincat-3-xa-performance.htm?id=1893330818933328

Click to expand...

I was wondering the same thing. I don't think its quite exactly the same thing as Peter is describing, but its close. Because the developer has control of the CPU cores in TwinCAT and can configure each to the application, you can mimic closely, if not exactly, what Peter is describing. In fact, we do this on almost all of our Beckhoff machines now. It's one of the most significant benefits to Beckhoff controllers.

I doubt the Beckoff computer is close to the Jetson Xavier AGX.
Read the specifications here.
https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-agx-xavier/
32 TOPS is a lot. That is tera operations. I doubt they are floating point units or they would have said TFOPS for tera floating point operations per second.

This is possible by using CUDA cores like what Nvidea uses on the graphics cards. 512 CUDA cores allow for parallel processing and the 64 Tensor cores allow using hardware for AI.

Over 10 years ago I was at a trade show in Atlanta, GA and saw this
https://deltamotion.com/peter/Videos/Daqota%20Scanner-desktop.mp4
At this time the engineers used the CUDA cores on multiple graphics cards in a PC and were limited by the number of slots to hold graphic cards in the PC.
This technology was used for optimizing veneer lathes. I used to write code and install veneer lathe scanner/optimizers in 1983-1985.

The CUDA cores also did some of the optimizing to find the best axis around which to rotate the log to get the longest and widest veneer sheets.

Back in 1983 I wrote a veneer optimizer using 32 bit integers on a CP/M machine.

I am going to experiment. Right now I can say I don't know what I don't know but I will find out. Have any of you heard me say anything like that before?

for me, language/syntax is irrelevant (they are all ugly, except ladder, of course )

Click to expand...

@drbitboy, I knew there was something wrong with you. C is the real deal and there is assembly language to do what C doesn't do well.

At home I have a GTX1080 in one of my computers it has 2560 CUDA cores. It is a chess playing monster. The CUDA cores also allow for faster video processing when using Handbrake.

Peter Nachtwey said:

@drbitboy, I knew there was something wrong with you.

Click to expand...

Yah I get that a lot. Took you this long to figger it out?

Peter Nachtwey said:

C is the real deal

Click to expand...

The only things I don't like about C are its proponents; it would be a great language if not for them.

I've written plenty in C; it's great if you have have to get close to the iron. I think it's even caught up to Fortran for performance (finally), but the portability is usually on the weak side of things.

Peter Nachtwey said:

and there is assembly language to do what C doesn't do well.

Click to expand...

I don't see the point of assembly if C is available, because C has all the power of assembler with all the convenience of assembler.

But seriously, the only thing that matters about a language are the available libraries for your application; anybody that does not get that is jes' plain ign'nt.

Peter Nachtwey said:

I doubt the Beckoff computer is close to the Jetson Xavier AGX.
Read the specifications here.
https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-agx-xavier/
32 TOPS is a lot. That is tera operations. I doubt they are floating point units or they would have said TFOPS for tera floating point operations per second.

Click to expand...

The GPU appears to be the difference. For one of Beckhoff's CX's or IPC's, there's no GPU's in that performance class from what I can see. However, you could get one of their desktop type industrial PC's and then install one or two high-end NVIDIA GPUs of your choice. That would certainly get you there and beyond(?)

drbitboy said:

But seriously, the only thing that matters about a language are the available libraries for your application; anybody that does not get that is jes' plain ign'nt.

Click to expand...

Which is why I'm such a big fan of CodeSys based controllers, and Python.

drbitboy said:

for me, language/syntax is irrelevant (they are all ugly, except ladder, of course ); libraries are what make the language choice for me.

Click to expand...

I love the structured nature of Pascal, and incidently it's cousin - Structured text.
Graphically im more of a Function block fan than ladder, perhaps its the european in me

ojz0r said:

I love the structured nature of Pascal, and incidently it's cousin - Structured text.
Graphically im more of a Function block fan than ladder, perhaps its the european in me

Click to expand...

There is no such thing as a structured programming language, only structured programmers.

drbitboy said:

I've written plenty in C; it's great if you have have to get close to the iron.

Click to expand...

When writing code for firmware for motion controllers or PLCs you are "close to the iron" all the time.

I think it's even caught up to Fortran for performance (finally), but the portability is usually on the weak side of things.

Click to expand...

It never was behind. Fortran had an advantage of having huge mathematical libraries written long ago but the Fortran language itself wasn't special. BTW, if you use pyinstaller to convert python code to an .exe you will find that the numpy and scipy libs are huge and written in gfortran.


C is very portable.

I don't see the point of assembly if C is available,

Click to expand...

That is because you haven't written firmware.

because C has all the power of assembler with all the convenience of assembler.

Click to expand...

No! While I agree that C is easier to write code with I don't agree that it is as "powerful". There are somethings you can't do in C like multiply a 16x16 bit number and get a 32 bit number then divide by a 16 bit number to get a a quotient and a remainder. C type casting gets in the way. I often hand to multiply by PI by multiplying by 355 then dividing by 113. I then would move the remainder into the high word and divide by 113 again to get an integer quotient and a fraction of 65536.

But seriously, the only thing that matters about a language are the available libraries for your application; anybody that does not get that is jes' plain ign'nt.

Click to expand...

No! not when you are writing firmware. Then you need the source to make sure all the variables and code are in the right place.

Peter Nachtwey said:

It never was behind. Fortran had an advantage of having huge mathematical libraries written long ago but the Fortran language itself wasn't special.


...


C is very portable.

Click to expand...

wrong on both counts, but everything else is okay.



just ask The Google about [performance c vs. fortran].



C is so so on portability, just take a look at all the #ifdef's in FOSS code; Fortran is far more portable.



Btw, the "all the power ... with all the convenience..." line was humor.

Peter Nachtwey said:

BTW, if you use pyinstaller to convert python code to an .exe you will find that the numpy and scipy libs are huge and written in gfortran.

Click to expand...

Fun offtopic fact: apparently the new Apple M1 chips weren't supported by a fortran compiler (last fall, not sure if that has since changed), which meant python libraries like numpy couldn't be used on that platform, even though the rest of python was OK.



one man's quest (not me):

https://www.hendrik-erz.de/post/setting-up-python-numpy-and-pytorch-natively-on-apple-m1