#126 #2
#126 #2
Conversation
pazzarpj
commented
Jan 11, 2023
pazzarpj
commented
- Updated protocol handlers to more reliably remove active waiters when task cancellation occurs
- Fixed checks where expecting a KeyError when it should be checking if not None
- Updated next_packet_id property to correctly check if there are any packet_ids available. Avoids infinite loop if all packet ids are used.
- Updated protocol handlers to more reliably remove active waiters when task cancellation occurs - Fixed checks where expecting a KeyError when it should be checking if not None - Updated next_packet_id property to correctly check if there are any packet_ids available. Avoids infinite loop if all packet ids are used.
|
Hello Pazzarpj, |
Hi, currently already authored a project that fits those needs. check pyfixate. https://github.com/PyFixate/Fixate |
|
Hi Ryan,
I guess that the biggest distinction I see is the user interface. I
worked in Systems Engineering and Systems Test at several defense
contractors and none of the systems engineers were software guys. They
can design the various tests to verify requirements but then would have
to turn everything over to software to write the actual tests. I want
them to be able to just enter commands, directives, limits, etc into a
spreadsheet. We did a demo of that using a spreadsheet as a front end
to National Instruments Test Stand and it worked extremely well. I want
to get away from NI though. The idea that you could enter the test
commands in a spreadsheet then run it in the lab initially on Raspberry
Pi based hardware would be great. They can move over to industrial
servers and ideally just run as is. In the defense contractor world
that would be huge.
Appreciate your quick response.
Regards,
Jared
…On 1/14/23 5:26 PM, Ryan Parry-Jones wrote:
Hello Pazzarpj, Hope this reaches you. I have a project I'd like
to get started that looks like it could be complementary to yours.
Please take a look here:
https://github.com/M1078/KDT-Test-Executive-Development Regards,
Jared Kondratuk ***@***.***
Hi, currently already authored a project that fits those needs. check
pyfixate. https://github.com/PyFixate/Fixate
—
Reply to this email directly, view it on GitHub
<#2 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMYFBHVEEEVBOEW4SG6K3YTWSMYYZANCNFSM6AAAAAATXTRBHE>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@M1078 Unfortunately, you cannot get the accuracy and degree of fidelity through a spreadsheet. Under the hood though, there needs to be domain specific knowledge implemented in order for those "blocks" of no code to exist. Take PyFixate for example. There is a JigDriver module that allows you to define hardware test points and map them to a relay matrix board. So the code looks like jig.mux("TP_1") But the jig driver had to be implemented on a per project basis to do all the hardware mapping. If you are dead set on the spreadsheet idea (No Code), you would need to have all the underlying systems and building blocks built (no different to test stand). Including your specific jig that you had designed built. Then you can have an adapter to translate the spreadsheet into workable solutions. Your situation seems to show that you write the tests and then hand over to the software guys. Maybe suggest a closer relationship with the software guys so they can build or adapt and existing framework to work within. If you can build using the pyfixate framework, then that is great. There are several electronic engineers using and maintaining the code base. There is no reason that a spreadsheet interface can't work with that framework providing the necessary under the hood work is done to map the spreadsheet line items to workable code. Personally, I find that just learning the basics and copy pasting existing examples of code is much better for the teams development (which is why my code is in python). One of my biggest gripes with using NI Test Stand is that piecing together the blocks was easy, but the moment something went wrong within the LabView blocks, then you get really stuck and have a much harder problem that even the software guys can't solve. |
|
Ryan,
I'm not advocating "No Code". The spreadsheet is just a front-end to
something like you've built. SET Pri_PWR ON maps to a function call
that sets a specific output pin/switch/relay to output a specified
voltage to power the UUT On. Measure command makes a voltage
measurement on a specific pin. And the Verify command here is a
function call to in this case an RS-485 serial monitor looking for a
specific word.
The actual test would have more steps than this but would be of a
similar style.
This spreadsheet format would also be used in the Test Executive GUI but
would then have Time and Measured values filled in and Pass or Fail
checked (or an X for fail). That would then feed into generating a test
report.
The advantage of a spreadsheet format for creating the test script is
that it is very easy to create using standard spreadsheet tools. And
easy to review. Some projects I've worked on have a very comprehensive
review cycle with most people not having a software background. So
having a spreadsheet that everyone can look over and understand makes
the process a lot easier.
Regards,
Jared
…On 1/15/23 6:28 PM, Ryan Parry-Jones wrote:
@M1078 <https://github.com/M1078>
One of the primary reasons I developed pyfixate was to get away from
NI Test Stand.
Unfortunately, you cannot get the accuracy and degree of fidelity
through a spreadsheet.
There is this notion of "No Code" or "Low Code" if you care to
research it.
Under the hood though, there needs to be domain specific knowledge
implemented in order for those "blocks" of no code to exist.
Take PyFixate for example. There is a JigDriver module that allows you
to define hardware test points and map them to a relay matrix board.
So the code looks like
jig.mux("TP_1")
dmm.voltage.dc.measure()
etc.
But the jig driver had to be implemented on a per project basis to do
all the hardware mapping.
In these cases we have had Electricians (Not systems or software
engineers) write the bulk of the test code.
If you are dead set on the spreadsheet idea (No Code), you would need
to have all the underlying systems and building blocks built (no
different to test stand). Including your specific jig that you had
designed built. Then you can have an adapter to translate the
spreadsheet into workable solutions.
Your situation seems to show that you write the tests and then hand
over to the software guys. Maybe suggest a closer relationship with
the software guys so they can build or adapt and existing framework to
work within.
If you can build using the pyfixate framework, then that is great.
There are several electronic engineers using and maintaining the code
base. There is no reason that a spreadsheet interface can't work with
that framework providing the necessary under the hood work is done to
map the spreadsheet line items to workable code.
Personally, I find that just learning the basics and copy pasting
existing examples of code is much better for the teams development
(which is why my code is in python). One of my biggest gripes with
using NI Test Stand is that piecing together the blocks was easy, but
the moment something went wrong within the LabView blocks, then you
get really stuck and have a much harder problem that even the software
guys can't solve.
—
Reply to this email directly, view it on GitHub
<#2 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMYFBHW35CFSWDSZQYM3JYDWSSI3HANCNFSM6AAAAAATXTRBHE>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
